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Foreword 



This Technical Specification (TS) has been produced by the Joint Technical Committee (JTC) Broadcast of the 
European Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the 
European Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in 
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television 
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters 
market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the 
broadcast industry. 
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Scope 



The present document of DVB-Simulcrypt addresses the requirements for interoperability between two or more 
conditional access systems at a head-end. It specifies the system architecture, timing relationships, messaging structures, 
extended interoperability and control. 

The components within the system architecture represent functional units. The boundaries between physical units are not 
required to match the boundaries between functional units. It is possible that the SCS could be in the MUX or the SCS 
and MUX could be built independently. Neither architecture is mandated. 



1.1 Common Scrambling Algorithm 



The DVB-Simulcrypt group has looked at issues relating to the concepts of the common scrambling algorithm, within 
the DVB-Simulcrypt environment. 

The DVB-Simulcrypt system is based on the concept of a shared scrambling and descrambling method. The group has 
looked at the possible constraints, which the DVB-Simulcrypt architecture might impose on the use of such a shared 
scrambling and descrambling method. No problems were noted. 



1 .2 Language 



The word "shall" is used in a normative statement that can be verified and is mandatory. The word "should" is used in 
the context of a recommendation or a statement that cannot be verified or is not mandatory (it may be optional). 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

broadcaster (service provider): organization which assembles a sequence of events or services to be delivered to the 
viewer based upon a schedule. 

CA_subsystem_id: CA_subsystem_id is defined in the present document to handle multiple connections to ECMGs 
with the same CA_system_id value. The combination of CA_system_id and CA_subsystem_id is called Super_CAS_id. 

CA_system_id: CA system IDs are defined in table 3 'CA_system_id' of ETSI ETR 162 [3]. 
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CA components: those components brought by a CA provider for integration into a host head-end system. 

channel: application specific representation of an open TCP connection, allowing the association of application specific 
parameters with such a connection. Channels correspond on a one to one basis to TCP connections. 

client: software entity on a host making use of one or more resources offered by a server. 

Conditional Access (CA) system: system to control subscriber access to broadcast services and events. 

Control Word (CW): data object used for scrambling. 

Control Word Generator (CWG): this component receives a CW request from the SCS and returns a CW. 

Crypto Period (CP): period when a particular Control Word is being used by the scrambler. 

Entitlement Control Message (ECM): private Conditional Access information, which carries the control word in a 
secure manner and private entitlement information. 

Entitlement Control Message Generator (ECMG): this generator produces the ECM messages but does not support 
ECM repetition. See subclause 4.2.3. 

Entitlement Management Message (EMM): private Conditional Access information which, for example, specifies the 
authorization levels of subscribers or groups of subscribers for services or events. 

Entitlement Management Message Generator (EMMG): produces the EMM messages and repeatedly plays them out 
at the appropriate times. See subclause 4.2.4. 

forbidden: term "forbidden" when used in (the) clauses indicates that the value shall never be used. 

generator: component producing data. 

host: computer system uniquely identified by its IP address, and as such addressable in a computer network. It may take 
both client and server roles. 

host head-end: system which is composed of those components required before a CA provider can be introduced into 
the head-end. 

MPEG-2: refers to the standard ISO/IEC 13818-1 [7]. Systems coding is defined in part 1. Video coding is defined in 
part 2. Audio coding is defined in part 3. 

multiplex: stream of all the digital data within a single physical channel carrying one or more services or events. 

Multiplexer (MUX): see subclause 4.2.9. 

Private Data Generator (PDG): see subclause 4.2.5. 

proprietary: this term details the fact that the interface will be specified by the head-end provider, or by the 

CA provider. The interface can be commercially open but is not open within the present document. Its availability will 

be via commercial/technical agreement. 

reserved: term "reserved" when used in the clause defining the coded bit stream, indicates that the value may be used in 
the future for ISO defined extensions. Unless otherwise specified within the present document all "reserved" bits shall 
be set to "1". 

Rreserved future use: term "reserved_future_use", when used in the clause defining the coded bit stream, indicates that 
the value may be used in the future for ETSI defined extensions. Unless otherwise specified within the present document 
air'reserved_future_use " bits shall be set to "1". 

Rresource: set of coherent functions, accessible through a server. More than one resource can reside on a single host. 

Scrambler (SCR): see subclause 4.2.10. 

server: software entity exporting a resource. More than one server may reside on a single host. A server is uniquely 
identified by an IP address and TCP port number. 

service: sequence of events under the control of a broadcaster, which can be broadcast as part of a schedule. 
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Service Information (SI): information that is transmitted in the transport stream to aid navigation and event selection. 

SI generator: see subclause 4.2.8. 

Simulcrypt Integrated Management Framework (SIMF): addresses the requirements for interoperability between 
management components of multiple conditional access systems (CASs) at a head-end (see clause 7). 

Simulcrypt Synchronizer (SCS): logical component that acquires Control Words, ECMs and synchronizes their 
playout for all the Conditional Access Systems connected. 

stream: independent bi-directional data flow across a channel. Multiple streams may flow on a single channel. 
Stream_ids (e.g. ECM_stream_id, data_stream_id, ...) are used to tag messages belonging to a particular stream. 

Super_CAS_id: super_CAS_id is a 32-bit identifier formed by the concatenation of the CA_system_id and the 
CA_subsystem_id. 

Transport Stream: data structure defined in ISO/IEC 13818-1 [7]. It is the basis of the ETSI Digital Video 
Broadcasting (DVB) standards. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ASN. I Abstract Syntax Notation One 

bslbf bit string, left bit first 

CA Conditional Access 

CAS Conditional Access System 

CAT Conditional Access Table 

CIM Common Information Model 

Conf Confirmation 

CORBA Common Object Request Broker Architecture 

CP Crypto Period 

CW Control Word 

CWG Control Word Generator 

DAVIC Digital Audio-Visual Council 

DVB Digital Video Broadcasting 

EBU European Broadcasting Union 

ECM Entitlement Control Message 

ECMG Entitlement Control Message Generator 

EFD Event forwarding discriminator 

EGP Exterior Gateway Protocol 

EIS Event Info Scheduler 

EIT Event Information Table 

EMM Entitlement Management Message 

EMMG Entitlement Management Message Generator 

Id Identifier 

IDL Interface Definition Language 

Ind Indication 

IP Internet protocol 

ISO International Organization for Standardization 

JMAPI Java Management API 

LSB Least Significant Bit 

MIB Management Information Base 

MJD Modified Julian Date 

MPEG Moving Pictures Expert Group 

MUX Multiplexer 

NIT Network Information Table 

NM Network Management 

OSI Open Systems Interconnection 

PAT Program Association Table 

PDG Private Data Generator 
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PID Packet Identifier 

PMT Program Map Table 

PSI Program Specific Information 

Req Request 

SCR DVB Compliant Scrambler 

SCS Simulcrypt Synchronizer 

SDT Service Description Table 

SI Service Information 

SIG Service Information Generator 

SIM Simulcrypt Identification Module 

SIMF Simulcrypt Integrated Management Framework 

SMI Structure of management information 

SMIB Simulcrypt Management Information Base 

SNMP Simple network management protocol 

ST Stuffing Table 

STB Set Top Box 

tcimsbf two's complement integer msb (sign) bit first 

TCP Transport Control Protocol 

TLV Type, Length, Value 

TMN Telecommunications management network 

UDP User Datagram Protocol 

uimsbf unsigned integer most significant bit first 

UTC Universal Time, Co-ordinated 



Architecture 



4.1 System Architecture 

Figure 1 shows the logical relationships between the components and which component-to-component interfaces are defined 
in the present document. Other components exist in a head-end, which are not illustrated in figure 1 (for example: SMS 
or Subscriber Management System. . .). 

The DVB-Simulcrypt system architecture illustrated above is divided into 3 areas. 



4.1 .1 Host Head-end components 



Host head-end components are those that will need to exist before Simulcrypt CA components can be introduced into a 
DVB-Simulcrypt head-end. 

4.1 .2 Simulcrypt CA components 

Simulcrypt CA components are typically those, which are brought by a new CA provider to introduce his CA into a 
DVB-Simulcrypt head-end. Note that the EMMGs, PDGs and Custom SI generators are not necessarily required in a DVB- 
Simulcrypt system. 

4.1 .3 Simulcrypt Integrated Management Framework (SIMF) 

The components of multiple conditional access systems (CASs) involved in a Simulcrypt architecture can be supported 
by a network management function existing in a head-end. 

For ECMG, EMMG, PDG, C(P)SIG and (P)SIG, a Simulcrypt Integrated Management Framework (SIMF) is defined to 
address the requirements for interoperability between management components at a head-end. This framework does not 
address all of the issues relevant for a complete integrated Simulcrypt Management System, it specifies only the 
minimum set of components necessary to enable integration. SIMF is described in clause 7. 
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Figure 1 : System Architecture 



4.2 Description of Components 

4.2.1 Event Info Scheduler (EIS) 

In the DVB-Simulcrypt system architecture diagram (subclause 4.1), the EIS is the functional unit in charge of holding 
the entire schedule information, all the configurations and CA specific information required for the complete system. It 
is the overall database store for the whole head-end system. For instance, it is in charge of providing to the ECMGs (via 
the SCS) any information they need to generate their ECMs. 

In reality this function might be distributed over several physical units, storage locations, and/or input terminals, and it 
may communicate with any other functional unit of the architecture diagram. 

Concerning the CA provider components, the connections to the EIS and the data they carry will be agreed through the 
commercial arrangements made with the broadcaster. They are not defined in the present document. 

4.2.2 Simulcrypt Synchronizer (SCS) 

The role of the Simulcrypt Synchronizer is to: 

establish TCP connections with ECMGs and setup one channel per connection; 
setup streams within channels as needed and allocate ECM_stream_id values; 
get the control words from the CWG; 
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supply the CWs to the relevant ECMGs on the relevant streams, as well as any CA specific information; 
- acquire ECMs from the ECMGs; 

synchronize the ECMs with their associated Crypto periods according to channel parameters; 
submit these ECMs to the MUX and request their repetition according to the channel parameters; 
supply the CW to the scrambler for use in the specified Crypto Period. 

4.2.3 ECM Generator (ECMG) 

The ECMG shall receive CWs in a CW provision message as well as access criteria and shall reply with an ECM or an 
error message. The ECMG does not support ECM repetition. 

4.2.4 EMM Generator (EMMG) 

This component, supplied by the CA provider shall interface over a DVB-Simulcrypt specified interface to the MUX. 
The EMMG initiates connections to the MUX. 

4.2.5 Private Data Generator (PDG) 

This component is shown in the DVB-Simulcrypt System Architecture diagram to highlight the fact that the EMMG to 
MUX interface can be used for EMMs and other CA related private data. The PDG initiates connections to the MUX. 



4.2.6 Custom (P)SI Generator (C(P)SIG) 



This component is responsible for generating private PSI descriptors and/or private SI descriptors. It interfaces to the 
(P)SI Generator. 

The generic term C(P)SIG refers to a head-end process that serves as a CPSIG, a CSIG, or both (CPSISIG). 

Custom PSI Generator (CPSIG): the CA System (CAS) process(es) responsible for generating CAS-specific private 
data for insertion in selected MPEG-2 PSI tables. 

Custom SI Generator (CSIG): the CAS process(es) responsible for generating CAS-specific private data for insertion 
in selected DVB SI tables. 

Each CAS may (optionally) include one or more C(P)SIG. 



4.2.7 MUX Config 



This component is responsible for configuring the MUX and providing a link to the PSI generator for PSI construction 
and playout. The interfaces 'MUX Config and MUX' and 'MUX Config and PSI Generator' are not defined by the 
present document. 



4.2.8 (P)SI Generator ((P)SIG) 



This component is responsible for generating the PSI (ISO/IEC 13818-1 [7]) and/or the SI (EN 300 468 [1]) for the 
system. The PSI Generator and/or the SI Generator take their primary data from the EIS and supplementary data from 
the Custom (P)S1 Generators supplied by the CA providers. The interfaces between the EIS and the (P)SI Generator and 
between the (P)SI Generator and the MUX are not defined by the present document. 

The generic term (P)SIG refers to a head-end process that serves as a PSIG, an SIG, or both PSISIG. 

PSI Generator (PSIG): the head-end process(es) responsible for generating MPEG-2 PSI (Program Specific 
Information) tables. 

SI Generator (SIG): the head-end process(es) responsible for generating DVB SI (Service Information) tables. 

NOTE: The NIT (Network Information Table) is considered a DVB SI table. 
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If the head-end supports the C(P)SIG •^ (P)SIG interface, it shall include one or more (P)SIG. 

4.2.9 Multiplexer (MUX) 

The role of this head-end component is to perform time multiplexing of input data, and to output an MPEG-2 transport 
stream. The input data can be transport packets, MPEG sections or raw data. The exact functionality of a MUX is 
implementer specific. For the purpose of the present document, the MUX shall be able to communicate with the SCS, 
the (P)SIG and to accept connections with EMMGs with the interface defined. 

4.2.10 Scrambler (SCR) 

This component is responsible for scrambling data in the MPEG2 Transport Ttream. The exact functionality of the 
Scrambler is implementer specific. For the purpose of the present document, the Scrambler shall be able to receive 
Control Words from the SCS. 

4.2.1 1 Control Word Generator (CWG) 

This component is responsible for generating control words used in scrambler initialization stream. The exact 
functionality of the Scrambler is implementer specific. For the purpose of the present document, the Control Word 
Generator shall be able to provide the SCS with control words. 

4.2.1 2 Network Management System (NMS) 

This component is responsible for monitoring and control of SIMF agents. The exact nature of this function depends on 
the type of host component the agent is situated in, i.e. ECMG, EMMG, PDG, etc, and the type of management function 
the NMS component is performing, i.e. fault, configuration, accounting, performance and security management. 



4.2.13 SIMF agent 

This component supports network management protocol transactions on the Simulcrypt Management Information Base 
(SMIB), which it implements. It instruments the SMIB with monitoring and control functionality of the host component, 
i.e. ECMG, EMMG, PDG, etc. 

4.3 Description of interfaces 

4.3.1 ECMG ^ SCS 

The interface allowing a CAS to provide a SCS with ECMs under the control of this SCS. This interface is mandatory 
and shall be implemented as described in clause 5. 

4.3.2 EMMG ^ MUX 

The interface allowing a CAS to provide a MUX with EMM under the control of the CAS. This interface is mandatory 
and shall be implemented as described in clause 6. 

4.3.3 PDG ^ MUX 

The interface used is the EMMG <^ MUX interface. 

4.3.4 Custom (P)SI Generator ^ (P)SI Generator 

The interface allowing a CAS to provide a (P)SIG with private data descriptors for the head-end to insert in (P)SI tables. 
This interface is mandatory and shall be implemented as described in clause 8. 
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4.3.5 EIS ^ SI Generator 

Proprietary, not defined by the present document. 

4.3.6 SI Generator ^ MUX 

Proprietary, not defined by the present document. 

4.3.7 EIS ^ MUX Config 

Proprietary, not defined by the present document. 

4.3.8 MUX Config ^ PSI Generator 

Proprietary, not defined by the present document. 

4.3.9 PSI Generator ^ MUX 

Proprietary, not defined by the present document. 

4.3.10 MUX ^ SCR 

Proprietary, not defined by the present document. 

4.3.11 SCR onward 

Proprietary, not defined by the present document. 

4.3.12 SCS^MUX 

Proprietary, not defined by the present document. 

4.3.13 SCS^SCR 

Proprietary, not defined by the present document. 

4.3.14 SCS^CWG 

Proprietary, not defined by the present document. 

4.3.15 EIS^SCS 

Proprietary, not defined by the present document. 

4.3.16 NMS Component ^ SIMF Agent 

This interface allows a network management function existing in a head-end to support Simulcrypt CA components. It is 
defined by the Simulcrypt MIB and the NM protocol used in the system. 

This interface is optional; if used it shall be implemented as described in clause 7. 

4.3.1 7 Mandatory or optional characteristics of the interfaces 

The subclauses 4.3.1 to 4.3.16 give the global mandatory or optional characteristic of each interface described in the 
present document. Table la sums up these characteristics. 
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Table la: Mandatory or optional characteristics of the Simulcrypt interfaces 



Interfaces 


Global 
characteristic 


Particular points 


See subclauses 


ECMG ^ SCS 


mandatory 


only TCP based implementation 
Security of control words: 

• GW security shall be supported; the means or methods to 
support this security are chosen by commercial agreement; 
one of them is the GW encryption in the protocol; 

• GW encryption in the protocol is optional if GWs are 
encrypted in the protocol, the method given in annex D is 
recommended. 


5.1.7 


EMMG ^ MUX 


mandatory 


a real implementation is chosen by the head-end operator 
among: 

• TCP based implementation for data provision and control; 

• UDP based implementation for data provision and TCP 
based implementation for control; 

• UDP based implementation for data provision and SIMF 
based implementation for control. 


6.1 


C(P)SIG«(P)SIG 


mandatory 


according to the same application protocol model, a real 
implementation is defined by commercial agreement among: 

• TCP based implementation; 

• SIIVIF based implementation. 


8.2 


NMS Component 
t^SIMF Agent 


optional 


the Simulcrypt Network IVIanagement function implementation is 
optional and is defined by the head-end operator among: 

• SNMP v2 for agents and manager; this implementation is 
fully defined in the present document; 

• SNMP v2 for agents and GORBA for manager; in this case 
only the SNMP v2 compliant SMIB is described in the 
present document. 


7.1 



4.4 Protocol types 

4.4.1 Connection-oriented protocols 

For the connection-oriented protocols defined in the present document, the messages shall have the following generic 
structure: 



Table 1b: Message-type values for command/response-based protocols 



generic_message 

{ 

protocol„version 1 byte 
message„type 2 bytes 
message_length 2 bytes 
for (i=0; i < n; i++) 



parameter_type 2 bytes 
parameter_length 2 bytes 
parameter_value <parameter_length> bytes 



NOTE 1 : For parameters with a size two or more bytes the first byte to be transmitted will be the most significant 
byte. 

NOTE 2: Parameters do not need to be ordered within the generic message. 

protocol_version: A 8 bit field identifying the protocol version. It shall have the value 0x02. 

message_type: A 16 bit field identifying the type of the message. The list of message type values is defined in table 2. 
Unknown message types shall be ignored by the receiving entity. 
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messagejength: 16-bit field specifies the number of bytes in the message immediately following the message_length 
field. 

parameter_type: 16-bit field specifies the type of the following parameter. The list of parameter type values is defined 
in the interface specific sections of the present document. Unknown parameters shall be ignored by the receiving entity. 
The data associated with that parameter will be discarded and the remaining message processed. 

parameterjength: 16-bit field specifies the number of bytes of the following parameter_value field. 

parameter_value: variable length field specifies the actual value of the parameter. Its semantics is specific to the 
parameter type value. 
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Table 2: Message-type values for command/response-based protocols 



Relevant interface 


Message_type value 


Message type 


DVB reserved 


0x0000 


DVB reserved 


ECMG «> SCS 


0x0001 
0x0002 
0x0003 
0x0004 
0x0005 


channel_setup 
channeljest 
channel_status 
channel_close 
channel error 


DVB reserved 


0x0006 to 0x001 


DVB reserved 


EMMG ^ MUX 


0x001 1 
0x0012 
0x0013 
0x0014 
0x0015 


channel_setup 
channeljest 
channel_status 
channel_close 
channel error 


DVB reserved 


0x0016 to 0x0100 


DVB reserved 


ECMG «> SOS 


0x0101 
0x0102 
0x0103 
0x0104 
0x0105 
0x0106 


stream_setup 

streamjest 

stream_status 

stream_close_request 

stream_close_response 

stream error 


DVB reserved 


0x1 07 to 0x1 10 


DVB reserved 


EMMG o MUX 


0x01 1 1 
0x0112 
0x0113 
0x0114 
0x0115 
0x0116 
0x0117 
0x0118 


stream_setup 

streamjest 

stream_status 

stream_closejequest 

stream_closejesponse 

stream_error 

stream_BW_request 

stream BW allocation 


DVB reserved 


0x01 19 to 0x0200 


DVB reserved 


ECMG ^ SCS 


0x0201 
0x0202 


CW_provision 
ECM response 


DVB reserved 


0x0203 to 0x0210 


DVB reserved 


EMMG « MUX 


0x021 1 


data_provision 


DVB reserved 


0x0212 to 0x0300 


DVB reserved 


C(P)SIG ^ (P)SIG 


0x0301 
0x0302 
0x0303 
0x0304 
0x0305 


channel_setup 
channel_status 
channeljest 
channel_close 
channel error 


DVB reserved 


0x0306 to 0x0310 


DVB reserved 


C(P)SIG ^ (P)SIG 


0x031 1 
0x0312 
0x0313 
0x0314 
0x0315 
0x0316 
0x0317 
0x0318 
0x0319 
0x031 A 
0x031 B 
0x031 C 
0x031 D 
0x031 E 
0x031 F 
0x0320 
0x0321 


stream_setup 

stream_status 

streamjest 

stream_close 

stream_closejequest 

stream_closejesponse 

stream_error 

stream_service_change 

stream Jrigger_enablejequest 

stream Jrigger_enablejesponse 

trigger 

tablejequest 

tablejesponse 

descriptorjnsertjequest 

descriptorjnsertjesponse 

PIDprovisionrequest 

PID provision response 


DVB reserved 


0x0322 to 0x7FFF 


DVB reserved 


user defined 


0x8000 to OxFFFF 


user defined 
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4.4.2 SIMF-based protocols 



All Simulcrypt CAS/Head-end interface specifications such as ECMG <^ SCS, EMMG <^ Mux, PDG <^ Mux, and 
C(P)SIG -^ (P)SIG are based on a connection-oriented communications paradigm (i.e. channel/streams). Alternatively, 
all these interfaces can be implemented using a transaction-based communications paradigm using the SIMF. In the 
current Simulcrypt specification this alternative is only available: 

- for the C(P)SIG ^ (P)SIG interface; 

- for the control of UDP-based protocol on EMMG/PDG <^ Mux interface. 

5 ECMG ^ SCS interface 

5.1 Interface principles 

5.1 .1 Channel and Stream specific messages 

This interface shall carry the following channel messages defined further in subclause 5.4: 

• Channel_setup 

• Channel_test 

• Channel_status 

• Channel_close 

• Channel_error 

and the following stream messages defined further in subclause 5.5: 

• Stream_setup 

• Stream_test 

• Stream_status 

• Stream_close_request 

• Stream_close_response 

• Stream_error 

• CW_provision 

• ECM_response 

For this interface, the SCS is the client and the ECMG is the server. The SCS has a prior knowledge of the mapping 
between Super_CAS_ids and the IP addresses and port numbers of the ECMGs. When a new ECM stream is requested 
by the EIS for a given Super_CAS_id value, the SCS will open a new stream with the appropriate ECMG. This might 
require the opening of a new channel (which involves the opening of a new TCP connection). 

When a new ECM stream is created in a transport stream, a new ECM_id shall be assigned to it by the head-end, 
according to the operational context (ECM stream creation or ECMG replacement). The value of the ECM_id parameter 
remains unmodified as long as the ECM stream exists. The combination {« ECM » type + Super_CAS_id + ECM_id} 
identifies uniquely this new ECM stream in the whole system. 

NOTE: There can be several ECMGs associated with the same Super_CAS_id value (e.g. for performance or 

redundancy reasons). In such a case the SCS should be able to choose with which ECMG the connection 
will be opened, based on either a redundancy policy or resource available. 
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5.1.2 Channel establishment 



There is always one (and only one) channel per TCP connection. Once the TCP connection is established, the SCS sends 
a channel_setup message to the ECMG. In case of success the ECMG replies by sending back a channel_status message. 

In case of a rejection or a failure during channel setup the ECMG replies with a channel_error message. This means that 
the channel has not been opened by the ECMG and the SCS shall close the TCP connection. 

5.1.3 Stream establishment 

The SCS sends a stream_setup message to the ECMG. In case of success the ECMG replies by sending back a 
stream_status message. In case of a rejection or a failure the ECMG replies with a stream_error message. 

Once the connection, channel and stream have been correctly established the ECM will be transferred. It can be 
transferred as sections or as TS packets. The ECMG indicates at channel setup which kind of data object will be used. 

Once the connection, channel and stream have been correctly established, ECMs will be transferred to the SCS as a 
response to the CW_provision message. 

5.1.4 Stream closure 

Stream closure is always initiated by the SCS. This can occur when an ECM stream is no longer needed or in the case of 
an error. This is done by means of a stream_close_request message. A stream_close_response message indicates the 
stream has been closed. 

5.1.5 Channel closure 

Channel closure can occur when the channel is no longer needed or in case of error (detected by SCS or reported by 
ECMG). This is done by means of a channel_close message sent by the SCS. Subsequently, the connection shall be 
closed by both sides. 

5.1 .6 Channel/Stream testing and status 

At any moment either component can send a channel_test/stream_test message to check the integrity of a 
channel/stream. In response to this message the receiving component shall reply with either a channel/stream status 
message or a channel/stream error message. 



5.1.7 Unexpected communication loss 



Both SCS and ECMG shall be able to handle an unexpected communication loss (either on the connection, channel or 
stream level). 

Each component, when suspecting a possible communication loss (e.g. a 10 second silent period), should check the 
communication status by sending a test message and expecting to receive a status message. If the status message is not 
received in a given time (implementation specific) the communication path should be re-established. 



5.1 .8 Handling data inconsistencies 



If the ECMG detects an inconsistency it shall send an error message to the SCS. If the SCS receives such a message or 
detects an inconsistency it may close the connection. The SCS (as the client) will then (re-)establish the connection, 
channel and (if applicable) streams. 

NOTE: The occurrence of a user defined or unknown parameter_type or message_type shall not be considered as 
an inconsistency. 
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5.2 Parameter_type values 



Table 3: ECMG protocol parameter_type values 



Parameter type Value 


Parameter type 


Type/units 


Length (bytes) 


0x0000 


DVB Reserved 


- 


- 


0x0001 


Super_CAS_id 


uimsbf 


4 


0x0002 


section_TSpkt_flag 


Boolean 


1 


0x0003 


delay_start 


tcimsbf/ms 


2 


0x0004 


delay_stop 


tcimsbf/ms 


2 


0x0005 


transition_delay_start 


tcimsbf/ms 


2 


0x0006 


transition_delay_stop 


tcimsbf/ms 


2 


0x0007 


ECM_rep_period 


uimsbf/ms 


2 


0x0008 


max_streams 


uimsbf 


2 


0x0009 


min CP duration 


uimsbf/n x 100ms 


2 


OxOOOA 


lead_CW 


uimsbf 


1 


OxOOOB 


CW_per_msg 


uimsbf 


1 


OxOOOC 


max_comp_time 


uimsbf/ms 


2 


OxOOOD 


access_criteria 


user defined 


variable 


OxOOOE 


ECM_channel_id 


uimsbf 


2 


OxOOOF 


ECM_stream_id 


uimsbf 


2 


0x0010 


nominal_CP_duration 


uimsbf/n x 100ms 


2 


0x001 1 


access_criteria_transfer_mode 


Boolean 


1 


0x0012 


CP_number 


uimsbf 


2 


0x0013 


CP_duration 


uimsbf/n x 100ms 


2 


0x0014 


CP CW Combination 


— 


variable 




CP 


uimsbf 


2 




CW 


uimsbf 


variable 


0x0015 


ECIVI_datagram 


user defined 


variable 


0x0016 


AC_delay_start 


tcimsbf/ms 


2 


0x0017 


AC_delay_stop 


tcimsbf/ms 


2 


0x0018 


CW encryption 


user defined 


variable 


0x0019 


ECM id 


uimsbf 


2 


OxOOIAtoOxGFFF 


DVB reserved 


- 


- 


0x7000 


Error_status 


see subclause 5.6 


2 


0x7001 


Error information 


user defined 


variable 


0x7002 to 0x7FFF 


DVB reserved 


- 


- 


0x8000 to OxFFFF 


User defined 


- 


- 



5.3 



Parameter semantics 



AC_delay_start: this parameter shall be used in place of the delay start parameter for the first Crypto period following 
a change in AC. 

AC_delay_stop: this parameter shall be used in place of the delay stop parameter for the last Crypto period preceding a 
change in AC. 

access_criteria: this parameter contains CA system specific information of undefined length and format, needed by the 
ECMG to build an ECM. It can be, for example, a pointer to an access criterion in an ECMG database, or a list of 
relevant access criteria items in an encapsulated TLV format. This parameter contains the information related to the CP 
indicated in the CW_provision message. The presence and contents of the access criteria parameter are the result of CA 
system supplier requirements. 

access_criteria_transfer_mode: this 1-byte parameter is a flag. If it equals 0, it indicates that the access_criteria 
parameter is required in the CW_pro vision message only when the contents of this parameter change. If it equals 1, it 
indicates that the ECMG requires the access_criteria parameter be present in each CW_provision message. 

CP_CW_combination: this parameter is the concatenation of the Crypto period number the control word is attached to 
and the control word itself. The parity (odd or even) of the Crypto Period number is equal to the parity of the 
corresponding control word (see ETSI ETR 289 [5]). This parameter is typically 10 byte long. 

CP_duration: this parameter indicates the actual duration of a particular Crypto period for a particular stream when it 
differs from the nominal_CP_duration value (see definition below). 
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CP_number: an identifier to a Crypto period. This parameter indicates the Crypto period number a message is attached 
to. This is relevant for the following messages: CW_provision, and ECM_response. 

CW_encryption: this parameter enables encrypting of control words over the SCS <^ ECMG interface. If the parameter 
is included in the CW_provision message, control word scrambling is invoked; if omitted, CWs are being issued in the 
clear. This parameter may include sub-parameters according to the used encrypting method. It may be used by the CW 
security method described in annex D or by an equivalent method. 

CW_per_msg: the number of control words needed by the ECMG per control word provision message. If this value is 
'y' and lead_CW is 'x', each control word provision message attached to Crypto period 'n' will contain all control words 
from period (n+l+x-y) to period (n+x). Control words are carried with their Crypto period number by means of the 
CP_CW_combination parameter. In most existing CA systems CW_per_msg is 1 or 2. See also lead_CW. 

For example, if an ECMG requires the current and next control word to generate an ECM, it shall by definition specify 
at least one lead_CW. However, since it may buffer its own control words, it can set CW_per_msg to one. By doing this, 
it always receives the control word for the next Crypto Period and accessing the control word for the current Crypto 
Period from memory (a previous provision message). Alternatively, it may specify 2 CW_per_msg and have both 
control words available at ECM generation time. This eliminates the need for ECMG buffering and can be advantageous 
for a hot backup to take over, since each provision message includes all control words required. 

An SCS shall minimally support CW_per_msg values 1 and 2. 

delay_start: this signed integer represents the amount of time between the start of a Crypto Period, and the start of the 
broadcasting of the ECM attached to this period. If it is positive, it means that the ECM shall be delayed with respect to 
the start of the Crypto Period. If negative, it means that the ECM shall be broadcast ahead of this time. This parameter is 
communicated by the ECMG to the SCS during the channel setup. 

delay_stop: this signed integer represents the amount of time between the end of a Crypto Period, and the end of the 
broadcasting of the ECM attached to this period. If it is positive, it means that the end of the ECM broadcast shall be 
delayed with respect to the end of the Crypto Period. If negative, it means that the ECM broadcast shall be ended ahead 
of time. This parameter is communicated by the ECMG to the SCS during the channel setup. 

ECM_channel_id: the ECM_channel_id is allocated by the SCS and uniquely identifies an ECM channel across all 
connected ECMGs. 

ECM_id: the ECM_id is allocated by the head-end and uniquely identifies an ECM stream for a Super_CAS_id. The 
combination of the « ECM » type, the Super_CAS_id and the ECM_id identifies uniquely an ECM stream in the whole 
system. The unique identifier principle is described in subclause 8.2.7. 

ECM_datagrain: the actual ECM message to be passed by the SCS to the MUX. It can be either a series of transport 
packets (of 188 byte length) or an MPEG-2 section, according to the value of section_TSpkt_flag. The ECM datagram 
can have a zero length meaning that there is no ECM to be broadcast for the crypto period. The ECM datagram shall 
comply with ETSI ETR 289 [5]. 

ECM_rep_period: this integer represents the period in milliseconds for the repetition of data (e.g. ECMs). 

ECM_stream_id: this identifier uniquely identifies an ECM stream within a channel. It is allocated by the SCS prior to 
stream setup. 

error_status: see subclause 5.6. 

error_information: this optional parameter contains user defined data completing the information provided by 
error_status. It can be an ASCII text or the parameter ID value of a faulty parameter for example. 

lead_CW: the number of control words required in advance to build an ECM. If this value is 'x' the ECMG requires 
control words up to Crypto Period number 'n-nx' to build the ECM attached to Crypto period 'n'. In most existing CA 
systems lead_CW is or 1 . See also CW_per_msg. 

For example, if the ECMG requires the current and next control word to generate an ECM, lead_CW would be 1 . In 
other words, it defines the most future control word required for ECM generation. 

An SCS shall minimally support lead_CW values and 1 . 
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max_comp_time: this parameter is communicated by the ECMG to the SCS during channel setup. It is the worst case 
time needed by an ECMG to compute an ECM when all the streams in a channel are being used. This time is typically 
used by the SCS to decide when to time-out on the ECM_response message. This value shall be lower than the 
min_CP_duration parameter of the same channel_status message. 

max_streains: maximum number of simultaneous opened streams supported by an ECMG on a channel. This parameter 
is communicated from the ECMG to the SCS during the channel setup. A value of means that this maximum is not 
known. 

inin_CP_duration: this parameter is communicated at channel setup by the ECMG to the SCS to indicate the minimum 
supported amount of time a control word shall be active before it can be changed. This value shall be greater than the 
max_comp_time parameter of the same channel_status message. 

noimnal_CP_duration: this parameter indicates the nominal duration of Crypto periods for the particular stream. It 
means that all the Crypto periods related to this stream will have this duration, except for the purpose of event 
alignments and error handling. Even in these exceptional cases, all the actual Crypto periods shall have a duration 
greater than or equal to the nominal_CP_duration. In addition, the nominal Crypto period duration (chosen by SCS) 
shall be greater than or equal to: 

all the min_CP_duration specified by the ECMGs during channel_setup; 

all the max_comp_time values specified by the ECMGs during channel setup, plus typical network latencies. 

section_TSpkt_flag: this parameter defines the format of the ECM carried on this interface: 

0x00: the ECMs carried on the interface are in MPEG-2 section format; 

0x01: the ECMs carried on the interface are in MPEG-2 transport stream packet format, all TS packets shall be 
188 byte long, any other payload length being considered as an error; it is the head-end's responsibility to fill the PID 
field in TS packet header; 

other values: DVB reserved. 

Super_CAS_id: the Super_CAS_id is a 32-bit identifier formed by the concatenation of the CA_system_id (16 bit) and 
the CA_subsystem_id (16 bit). It shall identify uniquely a (set of) ECMG(s) for a given SCS, see subclause 4.3.1. The 
CA_subsystem_id is defined by the user, it is private. 

transition_delay_start: this parameter shall be used in place of the delay start parameter for the first crypto period 
following a clear to scrambled transition. 

transition_delay_stop: this parameter shall be used in place of the delay stop parameter for the last crypto period 
proceeding a scrambled to clear transition. 

5.4 Channel specific IVIessages 

5.4.1 Channel_setup message: ECIVIG ^ SCS 



Parameter 


Number of instances in message 


ECM channel id 
Super CAS id 


1 
1 



The channel_setup message (message_type = 0x0001) is sent by the SCS to setup a channel once the TCP connection 
has been established, as described in subclause 5.1.2. It shall contain the Super_CAS_id parameter, to indicate to the 
ECMG to which CA system and subsystem the channel is intended (indeed, there could be several Super_CAS_ids 
handled by a single ECMG host). 
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5.4.2 Channeljest message: ECMG ^ SCS 



Parameter 


Number of instances in message 


ECM channel id 


1 



The channel_test message (message_type = 0x0002) can be sent at any moment by either side to check: 

the channel is in an error free situation; 

the TCP connection is still alive. 

The peer shall reply with a channel_status message if the channel is free of errors, or a channel_error message if errors 
occurred. 

5.4.3 Channel_status message: ECMG ^ SCS 



Parameter 


Number of instances in message 


ECM channel id 


1 


section TSpkt flag 


1 


AC delay start 


0/1 


AC_delay_stop 


0/1 


delay_start 


1 


delay_stop 


1 


transition delay start 


0/1 


transition delay stop 


0/1 


ECM_rep_period 


1 


max streams 


1 


min CP duration 


1 


lead CW 


1 


CWpermsg 


1 


max comp time 


1 



The channel_status message (message_type = 0x0003) is a reply to the channel_setup message or the channel_test 
message (see subclauses 5.1.2 and 5.1.6). 

When the message is a response to a setup, the values of the parameters are those requested by the ECMG. All these 
parameter values will be valid during the whole lifetime of the channel, for all the streams running on it. 

When the message is a response to a test, the values of the parameters shall be those currently valid in the channel. 

5.4.4 Channel_close message: ECMG ^ SCS 



Parameter 


Number of instances in message 


ECM channel id 


1 



The channel_close message (message_type = 0x0004) is sent by the SCS to indicate the channel is to be closed. 

5.4.5 Channel_error message: ECMG <-^ SCS 



Parameter 


Number of instances in message 


ECM_channel_id 
error_status 
error information 


1 

1 ton 
Oto n 



A channel_error message (message type = 0x0005) is sent by the recipient of a channel_test message or by the ECMG at 
any time to indicate that an unrecoverable channel level error occurred. A table of possible error conditions can be 
found in subclause 5.6. 
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5.5 
5.5.1 



Stream specific messages 
Stream_setup message: ECIVIG ^ SCS 



Parameter 


Number of instances in message 


ECM_channel_id 

ECM stream id 

ECMJd 

nominal CP duration 


1 
1 
1 

1 



The stream_setup message (message type = 0x0101) is sent by the SCS to setup a stream once the channel has been 
established, as described in subclause 5.1.3. 

5.5.2 Streamjest message: ECIVIG ^ SCS 



Parameter 


Number of instances in message 


ECIVI_channel_id 
EClVI stream id 


1 
1 



The stream_test message (message_type = 0x0102) is used to request a stream_status message for the given 
ECM_channel_id and ECM_stream_id. The stream_test message can be sent at any moment by either entity. The peer 
shall reply with a stream_status message if the stream is free of errors, or a stream_error message if errors occurred. 

5.5.3 Stream_status message: ECMG ^ SCS 



Parameter 


Number of instances in message 


ECIVI_channel_id 

EClVI stream id 

ECMJd 

access criteria transfer mode 


1 

1 
1 
1 



The stream_status message (message_type = 0x0103) is a reply to the stream_setup message or the stream_test message. 

When the message is a response to a setup, the value of the access_criteria_transfer_mode parameter is the one 
requested by the ECMG. 

When the message is a response to a test, the values of the parameters shall be those currently valid in the stream. 

5.5.4 Stream_close_request message: ECMG ^ SCS 



Parameter 


Number of instances in message 


ECIVl_channel_id 
EClVI stream id 


1 
1 



The ECM_stream_id is sent by the SCS in the stream_close_request message (message type = 0x0104) to indicate which 
of the streams in a channel is due for closure. 
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5.5.5 Stream_close_response message: ECMG -^ SCS 



Parameter 


Number of instances in message 


ECM_channel_id 
ECM stream id 


1 
1 



The ECM_stream_id is sent by the ECMG in the stream_close_response message (message type = 0x0105) to indicate 
which of the streams in a channel is closing. 

5.5.6 Stream_error message: ECMG ^ SCS 



Parameter 


Number of instances in message 


ECM_channel_id 
ECM_stream_id 
error_status 
error information 


1 

1 
1 ton 
Oton 



A stream_error message (message type = 0x0106) is sent by the recipient of a stream_test message or by the ECMG at 
any time to indicate that an unrecoverable stream level error occurred. A table of possible error conditions can be found 
in subclause 5.6. 

5.5.7 CW_provision message: ECMG ^ SCS 



Parameter 


Number of instances in message 


EClVI channel id 


1 


EClVI stream id 


1 


CP number 


1 


CW encryption 


Oto1 


CP CW combination 


CW per msg. 


CP duration 


Oto1 


access criteria 


Oto1 



CW_pro vision message (message_type 0x201) is sent by the SCS to the ECMG and serves as a request to compute an 
ECM. The value of the CP_number parameter is the Crypto period number of the requested ECM. The control words 
are carried by this message with their associated Crypto period numbers in the CP_CW_combination parameter, 
according to the value of lead_CW and CW_per_msg as defined during the channel setup. For instance, if lead_CW = 1 
and CW_per_msg = 2, the CW_provision message for Crypto period N shall contain control words for Crypto periods N 
andN+1. 

The SCS is not allowed to send a CW_provision message before having received the ECM_response message for the 
previous Crypto periods, except if there has been a time-out expiration, or an error message (in which case the way this 
error is handled is left to the discretion of the SCS manufacturer). 

The specific CWs that are passed in the CP_CW_combination to the ECMG via the CW_provision message are derived 
from the values of lead_CW and CW_per_msg. The following table shows a number of different values these 
parameters can take to achieve different ECMG requirements. 



Example 


Requirements 


lead CW 


CW_per_msg 


1 


1 CW per ECM per CP 





1 


2 


the CWs for the current and next CP per EClVI and the 
ECMG buffers the current CW from the previous CW 
Provision message 


1 


1 


3 


the CWs for the current and next CP per ECM and the 
ECMG receives both CWs from the SCS in each CW 
Provision message 


1 


2 


4 


3 CWs per ECM per CP 


1 


3 
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These graphs depict which CWs has to be passed for a specific CP, based on the different methods listed above. For any 
given CP, X-axis, the corresponding CW is portrayed on the Y-axis. In the CW_provision message, the boxed CWs are 
the set of CP_CW_combination that has to be passed. 




12 3 4 5 6 7 



CW 



12 3 4 5 6 7 



CP 




CP 



12 3 4 5 6 7 



Example 1 Example 2 





CP 



Example 3 Example 4 
Figure 2: Lead_CW to CW_per_msg relationship 

5.5.8 ECM_response message: ECMG -^ SCS 



Parameter 


Number of instances in message 


ECM_channel_id 
ECM_stream_id 
CP_number 
ECM datagram 


1 
1 
1 

1 
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The ECM_response message (message_type 0x202) is a reply to the CW_provision message. It carries the ECM 
datagram, computed by the ECMG, from the information provided by the CW_provision message (and possibly from 
other CA specific information). The value of the CP_number parameter shall be the same in the replied ECM_response 
message as in the previous incoming CW_provision message (on that stream). 

The time-out for the ECM_response message shall be computed by the SCS from the max_comp_time value defined 
during channel setup, and the typical network delays. 



5.6 



Error status 



NOTE: TCP connection level errors are beyond the scope of the present document. Only channel, stream and 
application level errors are dealt with. These errors occur during the lifetime of a TCP connection. 

There are two different error messages on these interfaces. The channel_error message for channel wide errors and the 
stream_error message for stream specific errors. These messages are sent by the ECMG to the SCS. When the ECMG 
reports an error to the SCS, it is up to the SCS to decide the most appropriate step to be taken. However 'unrecoverable 
error' explicitly means that the channel or stream (depending on the message used) has to be closed. Most of the error 
status listed in the table 4 cannot occur in normal operation. They are mainly provided to facilitate the integration and 
debugging phase. 

Table 4: ECMG protocol error values 



error status value 


Error type 


0x0000 


DVB Reserved 


0x0001 
0x0002 
0x0003 
0x0004 
0x0005 
0x0006 
0x0007 
0x0008 
0x0009 
OxOOOA 
OxOOOB 
OxOOOC 
OxOOOD 
OxOOOE 
OxOOOF 
0x0010 
0x001 1 
0x0012 
0x0013 
0x0014 
0x0015 


invalid message 
unsupported protocol version 
unknown messagejype value 
message too long 
unknown Super_CAS_id value 
unknown ECM_channel_id value 
unknown ECM_stream_id value 
too many channels on this ECMG 
too many ECM streams on this channel 
too many ECM streams on this ECMG 
not enough control words to compute ECM 
ECMG out of storage capacity 
ECMG out of computational resources 
unknown parameter_type value 
inconsistent length for DVB parameter 
missing mandatory DVB parameter 
invalid value for DVB parameter 
unknown ECMJd value 
ECM_channelJd value already in use 
ECM_streamJd value already in use 
ECM id value already in use 


0x0016 to 0x6 FFF 


DVB Reserved 


0x7000 
0x7001 


unknown error 
unrecoverable error 


0x7002 to 0x7FFF 
0x8000 to OxFFFF 


DVB Reserved 

ECMG specific / CA system specific / User defined 



5.7 Security in ECIVIG ^ SCS protocol 

The control words conveyed in the CP_CW_combination parameter within the CW_provision message constitute the 
clear cryptographic keys that are used to directly scramble content. Knowledge of these keys by unauthorized agents can 
result in the compromise of the security of the broadcast service. Therefore it is incumbent upon all Simulcrypt 
participants to employ effective and appropriate methods to preserve the confidentiality of the control words traversing 
this interface. One approach is to use only an inherently secure network for the ECMG <^ SCS interface. Another is to 
use a control word encryption scheme such as the one recommended in annex D of the present document to deliver the 
CW to the ECMG in a secure manner. In any case, the security of the CW on this interface shall be maintained so that 
unauthorized interception is prevented. 
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6 EMMG ^ MUX and PDG ^ MUX interfaces 

6.1 Transport layer protocols for EMMG/PDG ^ MUX 
interfaces 

To facilitate co-existence the DVB Simulcrypt Specification provides both TCP and UDP protocols for the 
EMMG/PDG <t=» MUX interface. This co-existence is not required within the same head-end. In certain head-ends the 
UDP protocol may be more suitable (e.g. for network performance reasons) and in other head-ends the TCP protocol 
may be more suitable (e.g. for network reliability reasons). Therefore it is the head-end operator that decides which 
protocol is more appropriate and should be followed. 



6.2 TCP-based protocol 
6.2.1 Interface principles 



6.2.1 .1 Channel and Stream specific messages 

The interface shall carry the following channel messages defined further in subclause 6.2.4: 

• Channel_setup 

• Channel_test 

• Channel_status 

• Channel_close 

• Channel_error 

and the following stream messages defined further in section 6.2.5: 

• Stream_setup 

• Stream_test 

• Stream_status 

• Stream_close_request 

• Stream_close_response 

• Stream_error 

• Data_provision 

For this interface, the EMMG/PDG is the client and the MUX is the server. In this TCP -based protocol, all messages are 
sent using TCP. 

6.2.1.2 Channel establishment 

The EMMG/PDG sends a channel_setup message to the MUX. In case of success the MUX replies by sending back a 
channel_status message. 

In case of a rejection or a failure during channel setup the MUX replies with a channel_error message. This means that 
the channel has not been opened by the MUX and the EMMG/PDG shall close the TCP connection. 
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6.2.1.3 Stream establishment 



The EMMG/PDG sends a stream_setup message to the MUX. In case of success the MUX replies by sending back a 
stream_status message. In case of a rejection or a failure the MUX replies with a stream_error message. 

When a new EMM/private data stream is created in a transport stream, a new data_id shall be assigned to it by the CAS, 
according to the operational context (EMM/private data stream creation or EMMG/PDG replacement). The value of the 
data_id parameter remains unmodified as long as the EMM/private data stream exists. The combination {stream 
type + client_id + data_id} identifies uniquely this new EMM/private data stream in the whole system. 

Once the connection, channel and stream have been correctly established the EMMs/private data will be transferred. 
They can be transferred as sections or as TS packets. The EMMG/PDG indicates at channel setup which kind of data 
object will be used. The EMMs/private data shall be inserted in the transport stream in the same order as they are 
provided by the EMMG/PDG. 

6.2.1.4 Bandwidth allocation 

The interface allows bandwidth negotiation between the EMMG/PDG and the MUX. This is not mandatory. During 
stream setup the EMMG/PDG will request the optimal bandwidth for that stream. The MUX will then respond with the 
bandwidth that has been allocated for that stream. The EMMG/PDG can, at a later time, request an adjustment in the 
bandwidth allocation. The MUX could also initiate an allocation change, without any request from the EMMG/PDG. 

6.2.1.5 Stream closure 

Stream closure is always initiated by the EMMG/PDG. This can occur when an EMM/private data stream is no longer 
needed. This is done by means of a stream_close_request message. A stream_close_response message indicates the 
stream has been closed. 

6.2.1.6 Channel closure 

Channel closure can occur when the channel is no longer needed or in case of error (detected by EMMG/PDG or 
reported by MUX). This is done by means of a channel_close message sent by the EMMG/PDG. Subsequently, the 
connection shall be closed by both sides. 

6.2.1 .7 Channel/Stream testing and status 

At any moment either component can send a channel_test/stream_test message to check the integrity of a 
channel/stream. In response to this message the receiving component shall reply with either a channel/stream status 
message or a channel/stream error message. 

6.2.1 .8 Unexpected connection loss 

Both EMMG/PDG and MUX shall be able to handle an unexpected communication loss (either on the connection, 
channel or stream level). 

Each component, when suspecting a possible communication loss (e.g. a 10 second silent period), should check the 
communication status by sending a test message and expecting to receive a status message. If the status message is not 
received in a given time (implementation specific) the communication path should be re-established. 

6.2.1 .9 Handling data inconsistencies 

If the MUX detects an inconsistency it shall send an error message to the EMMG/PDG. If the EMMG/PDG receives 
such a message or detects an inconsistency it should close the connection. The EMMG/PDG (as the client) will then 
(re-) establish the connection, channel and (if applicable) streams. 

NOTE: The occurrence of a user defined or unknown parameter_type or message_type shall not be considered as 
an inconsistency. 
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6.2.2 Parameter Type Values 



Table 5: EMMG/PDG protocol parameter_type values 



Parameter_type value 


Parameter type 


Type /Units 


Length (bytes) 


0x0000 


DVB Reserved 


- 


- 


0x0001 


client id 


uimsbf 


4 


0x0002 


section TSpkt flag 


boolean 


1 


0x0003 


data channel id 


uimsbf 


2 


0x0004 


data stream id 


uimsbf 


2 


0x0005 


datagram 


user defined 


variable 


0x0006 


bandwidth 


uimsbf / kbit/s 


2 


0x0007 


data type 


uimsbf 


1 


0x0008 


data id 


uimsbf 


2 


0x0009 to 0x6FFF 


DVB Reserved 


- 


- 


0x7000 


error status 


see subclause 6.2.6 


2 


0x7001 


error information 


user defined 


variable 


0x7002 to 0x7FFF 


DVB reserved 


- 


- 


0x8000 to OxFFFF 


user defined 


- 


- 



6.2.3 Parameter semantics 

bandwidth: this parameter is used in stream_BW_request and stream_BW_allocation messages to indicate the 
requested bit rate or the allocated bit rate respectively. It is the responsibility of the EMMG/PDG to maintain the bit rate 
generated within the limits specified by the MUX when the bandwidth allocation method is used (optional). It should be 
noted that the EMMG/PDG will operate from kbit/s to the negotiated rate. The EMMG/PDG will not exceed the 
negotiated rate. If the bandwidth allocation method is not used the responsibility of bit rate control is not defined in the 
present document. 

clientjd: the clientjd is a 32-bit identifier. It shall identify uniquely an EMMG/PDG across all the EMMGs/PDGs 
connected to a given MUX. To facilitate uniqueness of this value, the following rules apply: 

in the case of EMMs or other CA related data, the two first bytes of the client_id should be equal to the two bytes 
of the corresponding CA_system_id; 

in other cases a value allocated by DVB for this purpose should be used. 

data_stream_id: this identifier uniquely identifies an EMM/private data stream within a channel. 

data_channel_id: this identifier uniquely identifies an EMM/private data channel within a client_id. 

data_id: the data_id is allocated by the CAS and uniquely identifies an EMM/private data stream of a client_id. The 
combination of the client_id and the data_id identifies uniquely an EMM/private data stream in the whole system. The 
unique identifier principle is described in subclause 8.2.7. 

data_type: type of data carried in the datagram in the stream: 

- 0x00: EMM; 
0x01: private data; 

- 0x02: DVB reserved (ECM); 

other values: DVB reserved. 

datagram: this is the EMM/private data. The Datagram can be transferred in either section or TS packet format 
according to the value of section_TSpkt_flag. 

error_status: see subclause 6.2.6. 

error_information: this optional parameter contains user defined data completing the information provided by 
error_status. It can be an ASCII text or the parameter ID value of a faulty parameter for example. 
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section_TSpkt_flag: this parameter defines the format of the EMMs or of the private datagrams carried on this 
interface: 

0x00: the EMMs or private datagrams are in MPEG-2 section format; 

0x01: the EMMs or private datagrams are in MPEG-2 transport stream packet format; all TS packets shall be 
188 byte long, any other payload length being considered as an error; it is the head-end's responsibility to fill the FID 
field in TS packet header; 

other values: DVB reserved. 



6.2.4 
6.2.4.1 



Channel specific messages 

Channel_setup message: EMMG/PDG -^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channel_id 
section TSpkt flag 


1 
1 
1 



The channel_setup message (message_type = 0x001 1) is sent by the EMMG/PDG to the MUX to setup a channel once 
the TCP connection has been established, as described in subclause 6.2.1.2. It shall contain the client_id parameter 
indicating to the MUX the EMMG/PDG that is opening the channel. 



6.2.4.2 



Channeljest message: EMMG/PDG ^ MUX 



Parameter 


Number of instances in message 


clientjd 

data channel id 


1 
1 



The channel_test message (message_type = 0x0012) can be sent at any moment by either side to check: 

the channel is in an error free situation; 

the TCP connection is alive. 

The peer shall reply with a channel_status message if the channel is free of errors, or a channel_error message if errors 
occurred. 



6.2.4.3 



Ghannel_status message: EMMG/PDG ^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 

section_TSpktJlag 


1 

1 
1 



The channel_status message (message_type = 0x0013) is a reply to the channel_setup message or the channel Jest 
message (see subclauses 6.2.1.2 and 6.2.1.7). All the parameters listed above are mandatory. 

When the message is a response to a setup, the values of the parameters are those requested by the MUX. All these 
parameter values will be valid during the whole lifetime of the channel, for all the streams running on it. 

When the message is a response to a test, the values of the parameters shall be those currently valid in the channel. 
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6.2.4.4 



Channel_close message: EMMG/PDG -^ MUX 



Parameter 


Number of instances in message 


clientjd 

data channel id 


1 
1 



The channel_close message (message_type = 0x0014) is sent by the EMMG/PDG to indicate the channel is to be closed. 

6.2.4.5 Channel_error message: EMMG/PDG ^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 
error_status 
error information 


1 

1 
1 ton 
Oto n 



A channel_error message (message type = 0x0015) is sent by the recipient of a channel_test message or by the MUX at 
any time to indicate that an unrecoverable channel level error occurred. A table of possible error conditions can be 
found in subclause 6.2.6. 



6.2.5 
6.2.5.1 



Stream specific messages 

Stream_setup message: EMMG/PDG -^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 
data_stream_id 
data_id 
data type 





The stream_setup message (message_type = 0x01 1 1) is sent by the EMMG/PDG to setup a stream once the channel has 
been established, as described in subclause 6.2.1.3. 



6.2.5.2 



Streamjest message: EMMG/PDG ^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 
data stream id 


1 
1 

1 



The stream_test message (message_type = 0x01 12) is used to request a stream_status message for the given clientjd, 
data_channeljd and data_streamjd. The stream_test message can be sent at any moment by either entity. The peer 
shall reply with a stream_status message if the stream is free of errors, or a stream_error message if errors occurred. 



6.2.5.3 



Stream_status message: EMMG/PDG <^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 

data_stream_id 

data_id 

datajype 





The stream_status message (message_type = 0x01 13) is a reply to the stream_setup message or the stream_test message. 
The values of the parameters shall be those currently vahd in the stream. 
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6.2.5.4 



Stream_close_request message: EMMG/PDG -^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 
data stream id 


1 
1 

1 



The stream_close_request message (messagejype = 0x01 14) is sent by the EMMG/PDG to indicate the stream is to be 
closed. 



6.2.5.5 



Stream_close_response message: EMMG/PDG <— MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 
data stream id 


1 
1 
1 



The stream_close_response message (message_type = 0x01 15) is sent by the MUX indicating the stream that is being 
closed. 



6.2.5.6 



Stream_error message: EMMG/PDG <-^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 
data_stream_id 
error_status 
error information 


1 

1 

1 
1 ton 
Oton 



A stream_error message (message type = 0x01 16) is sent by the recipient of a stream_test message or by the MUX at 
any time to indicate that an unrecoverable stream level error occurred. A table of possible error conditions can be found 
in subclause 6.2.6. 



6.2.5.7 



Stream_BW_request message: EMMG/PDG -^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 
data_stream_id 
bandwidth 


1 
1 

1 
Oto1 



The stream_BW_request message (message type = 0x01 17) is always sent by the EMMG/PDG and can be used in two 
ways. 

If the bandwidth parameter is present the message is a request for the indicated amount of bandwidth. 

If the bandwidth parameter is not present the message is just a request for information about the currently allocated 
bandwidth. The MUX shall always reply to this message with a stream_BW_allocation message. 



6.2.5.8 



Stream_BW_allocation message: EMMG/PDG ^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channeljd 
data_stream_id 
bandwidth 


1 
1 

1 
Oto1 
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The stream_BW_allocation message (message type = 0x01 18) is used to inform the EMMG/PDG about the bandwidth 
allocated. This can be a response to a stream_BW_request message or as a notification of a change in bandwidth 
initiated by the MUX. The message is always sent by the MUX. 

If the bandwidth parameter is not present it means that the allocated bandwidth is not known. 

NOTE: The bandwidth allocation message may indicate a different bandwidth than was requested (this could be 
less). 



6.2.5.9 



Data_provision message: EMMG/PDG -^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channel_id 

data_stream_id 

data_id 

datagram 


1 
Oto1 
Oto1 

1 
1 ton 



The data_provision message is used by the EMMG/PDG to send, on a given data_stream_id, the datagram (in the case 
of EMMG this is EMM data). 

In the TCP -based protocol, the data_provision message shall include the data_channel_id and data_stream_id 
parameters. In the UDP-based protocol (see subclause 6.3), the data_provision message shall not include the 
data_channel_id and data_stream_id parameters. 

6.2.6 Error status 

NOTE: TCP connection level errors are beyond the scope of the present document. Only channel, stream and 
application level errors are dealt with. These errors occur during the lifetime of a TCP connection. 
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There are two different error messages on that interface. The channel_error message for channel wide errors, and the 
stream_error message for stream specific errors. These messages are sent by the MUX to the EMMG/PDG. When the 
MUX reports an error to the EMMG/PDG, it is up to the EMMG/PDG to decide the most appropriate step to be taken. 
However 'unrecoverable error' explicitly means that the channel or stream (depending on the message used) has to be 
closed. Most error status listed in table 6 cannot occur in normal operation. They are mainly provided to facilitate the 
integration and debugging phase. 

Table 6: EMMG/PDG protocol error values 



error status value 


Error type 


0x0000 


DVB Reserved 


0x0001 
0x0002 
0x0003 
0x0004 
0x0005 
0x0006 
0x0007 
0x0008 
0x0009 
OxOOOA 
OxOOOB 
OxOOOC 
OxOOOD 
OxOOOE 
OxOOOF 
0x0010 
0x001 1 
0x0012 
0x0013 
0x0014 


invalid message 
unsupported protocol version 
u Unknown message Jype value 
message too long 
unknown data_streamjd value 
unknown data_channeljd value 
too many channels on this IVIUX 
too many data streams on this channel 
too many data streams on this IVIUX 
unknown parameterjype 
inconsistent length for DVB parameter 
missing mandatory DVB parameter 
invalid value for DVB parameter 
unknown clientjd value 
exceeded bandwidth 
unknown datajd value 
data_channeljd value already in use 
data_streamjd value already in use 
datajd value already in use 
client id value already in use 


0x0015 to 0x6 FFF 


DVB Reserved 


0x7000 
0x7001 


unknown error 
unrecoverable error 


0x7002 to 0x7FFF 
0x8000 to OxFFFF 


DVB Reserved 

MUX specific / CA system specific / User defined 



6.3 UDP-based protocol 



The EMMG/PDG UDP-based protocol is using the same message format as described in subclause 6.2. Thanks to UDP 
functionality, it offers the unique advantage of broadcasting packets over a network and requires less network overhead; 
however, the EMMG/PDG UDP-based protocol does not provide additional feature to increase the intrinsic reliability of 
UDP. 



6.3.1 Interface principles 



In this protocol, only the data_provision message is sent using UDP/IP; it is the same message as the one used in the 
TCP-based protocol described in subclause 6.2.5.9. 

For the control part of this protocol, two methods can be used. The implementation of at least one of them is mandatory: 

the first method consists of using a TCP/IP connection supporting channel and stream management, as described 
in suclause 6.2.1. This connection carries also test, status, error and bandwidth negotiation messages. When UDP/IP 
broadcast is used to send EMMs or Private Data, it is the responsibility of the EMMG/PDG to open a TCP/IP 
connection with each multiplexer that needs to receive the UDP packets produced by the EMMG/PDG; 

the second method consists of using the Simulcrypt Management Framework described in clause 7. With this 
method, the Network Management System (NMS) is responsible for ensuring that the head-end components are 
configured properly to receive and process the EMM/Private data produced by the EMMG/PDG. 

The figure 3 illustrates the TCP -based version and the UDP-based version of the EMMG/PDG protocol. 
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Ctrl and data 



EMMG/PDG 
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TCP connection 



channel 



stream 

data-id allocation 
bandwidth negotiation 
data provision 
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TCP-based protocol 



Ctrl 
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data 



Ctrl 



TCP connection 
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data-id allocation 

bandwidth negotiation 
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data provision 



MUX1 



TCP 
(same) 



OR 



SIMF (same) 



MUX 2 



6.3.1.1 



UDP-based protocol 
Figure 3: TCP-based and UDP-based EMMG/PDG protocols 

Data_provision message: EMMG/PDG -^ MUX 



Parameter 


Number of instances in message 


clientjd 

data_channel_id 

data_stream_id 

data-id 

datagram 


1 
Oto1 
Otol 

1 
1 ton 



The data provision message is used by the EMMG/PDG to send, on a given data_id the datagram (in the case of EMMG 
this is EMM data). Data_channel_id and data_stream_id are optional parameters. The client_id/data_id pair shall 
identify in a unique manner an EMM/private data stream across the system. For example, if two EMMGs send an EMM 
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stream with the same data_id to the same multiplexer port, the multiplexer shall be able to distinguish between the two 
streams by looking at the client_id field in the data_provision message. 

This message is the only message sent over UDP/IP and can be broadcast to several multiplexers. 

6.3.1 .2 Channel and stream configuration messages 

Except for the data_provision message, all messages described in subclauses 6.2.4 and 6.2.5 can be used on a separate 
TCP/IP connection to manage channels and streams. If a broadcast mechanism is used to send data_provision messages, 
the client_id, data_stream_id and data_id parameters will be the same for all the Multiplexers processing the 
EMM/Private data stream. 

For this interface, the EMMG is the client, and the MUX is the server. Please refer to subclause 6.2 (TCP-based 
protocol) for syntax details. 

6.3.2 Bandwidth management 

When using channel and stream configuration messages with UDP/IP broadcast data_provision messages, the same 
bandwidth negociation messages need to be sent to all Multiplexers processing the EMM/private data stream: 

where TCP connections are used to manage configurations, it is the responsibility of the EMMG/PDG to ensure 
that all Multiplexers accept a new bandwidth configuration before changing the actual EMM/private data bandwidth. 
Multiplexers cannot be held responsible for overflow conditions on UDP/IP sockets; 

where SIMP is being used to manage configurations, it is the responsibility of the Network Management System 
(NMS) to ensure that all configuration changes are synchronized properly among the network components. For 
example, bandwidth increases shall first occur on the Multiplexers, while bandwidth decreases shall first occur on 
the EMMG/PDG to avoid loss of data. 



Network management 



7.1 S IMF overview 

The Simulcrypt Integrated Management Framework (SIMF) addresses the requirements for interoperability between 
management components of multiple conditional access systems (CASs) at a head-end. The framework does not address 
all of the issues relevant for a complete integrated Simulcrypt Management System. It specifies only the minimum set of 
components necessary to enable integration. 

All Simulcrypt CAS/head-end interface specifications such as ECMG <^ SCS, EMMG <^ Mux, PDG <^ Mux, and 
C(P)SIG <^ (P)SIG are defined based on a connection-oriented communications paradigm (i.e. channel/streams). 
Alternatively, all these interfaces can be implemented using a transaction-based communications paradigm using the 
SIMF. In the current Simulcrypt specification this alternative is only available for the C(P)SIG <^ (P)SIG interface. 

The basic specification principle of the SIMF is: 

to define a common information model for management of all Simulcrypt conditional access components within 
the head-end, which are directly related to the Simulcrypt protocol. Based on the Simulcrypt Common Information 
Model (CIM) the Simulcrypt Management Information Base (SMIB) is defined. The CIM defines management 
information specific to Simulcrypt conditional access components of a head-end such as the EMM Generators 
(EMMGs), ECM Generators (ECMGs), Custom Service Information Generators (CSIG) and Custom Program 
Specific Information Generators (CPSIG). The CIM also defines generic information enabling management 
facilitating functions such as event and alarm specification and logging; 

to define a management protocol for manager/agent communication. 
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7.1 .1 Introduction to the Common Information Model (CIM) 

The CIM provides a sufficiently large common denominator to ease the integration of basic management functions fault, 
configuration, and performance management into a head-end network manager or a conditional access system manager. 
Specifically, the CIM consists of the following information: 

1) configuration and status information of the following Simulcrypt conditional access components: 

- EMM Generators (EMMG); 
Private Data Generators (PDG); 

- ECM Generators (ECMG); 

- (P)SI Generator ((P)SIG); 

- C(P)SI Generator (C(P)SIG). 

2) generic event reporting information including: 

- event specification information; 

alarm, state change, and value change notifications; 
event forwarding information. 

3) generic log control mechanism including: 

log specification information; 

alarm, state change, value change logs; 

log filtering information. 

The CIM is implemented in the Simulcrypt Management Information Base (SMIB), which within the framework is 
realized in an open-ended fashion. This is necessary to not constrain a particular head-end in the choice of 
implementation technologies but to also simultaneously enable integration by providing a standard MIB. 

The management functions themselves are not mandated but are only enabled. 

Thus, the DVB Simulcrypt Integrated Management Framework (SIMF) standardizes management information access via 
a management protocol but does not specify how the management information is to be used. The framework consists of 
the following. 

1) The DVB Simulcrypt Management Information Base (SMIB)- using the basic concepts and vocabulary of the 
ITU-T TMN Information Model and the standard Internet SNMPv2 SMI, the SMIB consists of four modules: 

- MIB II as defined in RFC 1213 [6]; 

- the Simulcrypt Identification Module (SIM); 

- the Simulcrypt Events Module (SEM); 

- the Simulcrypt Logs Module (SLM). 

2) The management protocol to be used. 

A CIM description is given in subclauses 7.2 and 7.3. 



7. 1 .2 SIMF specialization options 



The framework enables the design and implementation of a complete integrated management system by specifying the 
common management information in the SMIB and a management protocol. To enable maximum flexibility in choosing 
the most appropriate technology for individual head-ends and facilitate open-endedness the following two 
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specializations of the SIMF are defined of which one shall be chosen if a management system is to be supported by a 
head-end (it is the head-end operator who decides which options are more appropriate): 

Option 1 - SNMP: 

- the SMIB is realized as an SNMPv2 SMI; 
the management protocol is SNMPv2. 

Option 2 - CORBA (not available for agents) (note): 

- the SMIB is realized as an IDL translation of the Option 1 SMI SMIB using the Joint X/Open/NMF (JIDM) 
specification; 

the management protocol is defined as the SNMPv2 equivalent based on the JIDM specification. 

NOTE: There is no obligation on a head-end management system to support CORBA agents. Only SNMP agents 
are always supported if the Simulcrypt Integrated Management Framework is implemented. 

The two options facilitate a variety of possible DVB Simulcrypt Management Systems including all current major 
approaches as follows: 

1) CORBA, TMN, TINA-C - see the OMG White Paper "CORBA-BASED Telecommunication Network 
Management Systems" which relies on the JIDM specification; 

2) JMAPI - JMAPI supports both SNMP and CORBA; 

3) WBEM - WBEM builds on top of existing frameworks. 

The present document fully defines only the SNMPv2 and SNMPv2 SMI based SMIB. 

The Simulcrypt Identification Module (SIM), the Simulcrypt Events Module (SEM) and the Simulcrypt Logs Module 
(SLM) can be used to support configuration, performance, and fault management of Simulcrypt components such as 
EMMG, ECMG, etc. While SIM is Simulcrypt specific, SEM and SLM also support generic notifications and logs and 
are applicable to any proprietary information modules. As such they can extend management functionality to the 
proprietary components if so desired by the component provider and the head-end facilitator. 

7.2 The Common Information Model 

The Common Information Model (CIM) definition is closely tied to SNMPv2 and SNMPv2 SMI, as this is the first 
option for a network management system realization, which can be transformed into the second one by means of the 
JIDM process. The Common Information Model specification maps directly into an SNMPv2 SMI MIB and therefore 
also includes the Internet Assigned Numbers Authority (lANA) Simulcrypt object number assignments. 

The Common Information Model consists of four modules: 

- MIB II as defined in RFC 1213 [6]; 

- the Simulcrypt Identification Module (SIM); 

- the Simulcrypt Events Module (SEM); 

- the Simulcrypt Logs Module (SLM). 

The Simulcrypt Identification Module (SIM) reflects the Simulcrypt interfaces specified (e.g. ECMG/SCS). Therefore it 
is specified after these interfaces have been specified. The other three modules are used in all systems and are the 
pre-requisite for management of any Simulcrypt interface or the implementation of a Simulcrypt interface using the 
transaction based approach, i.e. C(P)SI/(P)SI interface. 

The individual modules shall be implemented by Simulcrypt CA components if an integrated network management 
system is desired at the head-end and if a component is to be managed or monitored or if the interface is to be 
implemented using the transaction based transport. The technology underlying the module implementation can be 
different from component to component provided a JIDM based translator is provided to the common denominator 
platform of the head-end. For example, if the common denominator platform is CORBA and the module is implemented 
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in an ECM generator as an SNMP MIB then a JIDM gateway needs to be provided between CORBA/IIOP and SNMP. 
Not all network elements will have the need for all information groups defined in the modules. 



7.2.1 Object Containment Hierarchy 



Objects are unambiguously identified (or named) by assigning them an object identifier (OID). OIDs are globally unique 
for the entire Internet and are defined as a sequence of non-negative integers organized hierarchically similar to UNIX 
or DOS file system names. Each sequence element is also associated a textual name for ease of use. The last sequence 
name is commonly used by itself as a shorthand way of naming an object. Although there is no uniqueness requirement 
for shorthand names within the Internet- standard framework, by convention, an attempt is made to make those names 
unique by using a different prefix for objects in each new MIB. Figure 4 illustrates the Internet OID tree. 
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Figure 4: The Standard Internet OID Tree 

Different OID formats can be used by interchanging the component names and numbers. For example: 

{iso org(3) dod(6) internet(l)} and 1.3.6.1 define the same object which is the Internet; 

{internet 4} and 1.3.6.1.4 define the same object which is the Private branch of the Internet subtree; 

{tcp 4} and 1.3.6.1.1.2.1.6.4 define the same object which is the TCP MIB module of the standard Internet 
management MIB. 

For SNMP MIBs the following OID prefixes are important: 

internet defined as {iso(l) org(3) dod(6) 1 }; 

mgmt defined as { internet 2 } ; 

experimental defined as { internet 3 } ; 



£75/ 



45 



ETSI TS 103 197 VI. 1.1 (2000-06) 



- private defined as { internet 4 } ; 

mib, mib-l, and niib-2 which are defined as {mgmt 1 }; 

enterprises which is defined as {private 1 }. 

Objects for standard SNMP MIBs are defined under the "mib" branch of the hierarchy, "mib-l" has been superseded by 
"mib-2". Experimental MIBs being developed by IETF working groups define objects under the "experimental" branch. 
Proprietary MIBs define objects within an organization's subtree located under the "enterprises" branch (assigned by the 
Internet Assigned Numbers Authority - lANA). 

The number assigned to DVB by lANA is 2696. DVB Simulcrypt is assigned the first branch under DVB, which is 
{enterprises 2696 1} that corresponds to 1.3.6.1.4.1.2696.1. 

The DVB Simulcrypt MIB Modules are located as follows: 

- {simMlB} which is 1.3.6.1.4.1.2696.1.1; 

- {semMlB} which is 1.3.6.1.4.1.2696.1.2; 

- {slmMlB} which is 1.3.6.1.4.1.2696.1.3. 
Figure 5 illustrates the Simulcrypt MIB tree. 
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Figure 5: DVB Simulcrypt IVIIB Tree 



7.2.2 



MIB II 



MIB 11 is a standard Internet MIB (see RFC 1213 [6]). Every SNMP agent is assumed to support MIB II. MIB-II, hke 
its predecessor, the Internet-standard MIB, contains only essential elements. There is no need to allow individual objects 
to be optional. Rather, the objects are arranged into groups which are implemented by a system depending on whether 
the semantics of the group is applicable to an implementation. For example, an implementation has to implement the 
EGP group if and only if it implements the EGP. Following Groups are defined: 

System - Implementation of the System group is mandatory for all systems. The System group specifies things 
like system up time, system contact, system location, etc. If an agent is not configured to have a value for any of 
these variables, a string of length is returned. 

Interfaces - Implementation of the Interfaces group is mandatory for all systems. This group defines the different 
subnetwork interfaces from this entity, i.e. Ethernet, FDDI, etc. 

Address Translation (obsolete). 



£75/ 



46 ETSI TS 1 03 1 97 V1 .1 .1 (2000-06) 

IP - Implementation of the IP Group is mandatory for all systems. This group specifies information related to IP 
like routing tables, address mappings, statistics, etc. 

ICMP - Implementation of the ICMP group is mandatory for all systems. This group specifies a number of 
different type of statistics related to ICMP. 

TCP - Implementation of the TCP group is mandatory for all systems that implement the TCP. This group 
contains TCP configuration information and information about the existing TCP connections. Note that instances of 
object types that represent information about a particular TCP connection are transient; they persist only as long as 
the connection in question. 

UDP - Implementation of the UDP group is mandatory for all systems, which implement the UDP. This group 
contains UDP related statistics as well as information of all current UDP listeners. 

EGP - Implementation of the EGP group is mandatory for all systems, which implement the EGP. 

Transmission - Based on the transmission media underlying each on a system, the corresponding portion of the 
Transmission group is mandatory for that system. When Internet-standard definitions for managing transmission 
media are defined, the transmission group used to provide a prefix for the names of those. Typically, such definitions 
reside in the portion of the MIB until they are "proven", then as a part of the Internet standardization process, 
definitions are accordingly elevated and a new identifier, under the transmission group is defined. By convention, the 
name assigned is: type OBJECT IDENTIFIER: = {transmission number}, where "type" is the symbolic value used 
for the media in the ifType column of the ifTable object, and "number" is the actual integer value corresponding to 
the symbol. 

SNMP - Implementation of the SNMP group is mandatory for all systems which support an SNMP protocol 
entity. Some of the objects defined will be zero-valued in those SNMP implementations that are optimized to support 
only those functions specific to either a management agent or a management station. 



7.2.3 Concurrency Control 



Concurrency control of simultaneous updates of an agent's MIB variables by multiple managers is accomplished by 
using the SMIB SIM module's administrative state variables (as defined in the ITU-T Recommendation X.73 1 [8] 
standard used in TMN) and the SNMP administrative framework. An administrative state of a group of objects is either 
locked, unlocked, or shutting down. These states and the corresponding state transitions are defined in 
ITU-T Recommendation X.73 1 [8]. 

A manager can only lock a variable group if it is part of the agent's, module's, etc. management community and if the 
agent, module, etc. is not already locked. Once an agent is locked it is protected from access by other managers as any 
manager wanting to access the concurrency-controlled agent, module, etc. will first attempt to lock it and will fail if that 
is not possible (i.e. managers are trusted). If a manager should crash leaving the agent, module, etc. locked, the 
designated back-up managers within the same community can unlock the agent. 

7.2.4 The Simulcrypt Events Module (SEM) 

SEM enables managers to configure the types of events that can be generated by an agent and when those events should 
be transformed into asynchronous notifications (SNMP Traps) to be sent to different managers. The mechanism and 
information model used are based on the ITU-T Recommendations X.733 [9] and X.734 [10] standards defining event 
management and alarm reporting. SEM defines the following object groups: 

Events Group - This group consists of event configuration information defining the types of events that the agent 
shall generate. 

Event Forwarding Discriminator (EFD) Group - This group consists of FED configuration information defining 
what types of events an EFD will transform into notifications, at what times of day it will do so, and to which 
managers it will send the notifications to. 

Event Notifications - This group defines three types of notifications, which an agent can send to a manager. 
These are an alarm, a state change notification, and a value change notification. Each EFD specifies what type of 
notification is to be sent for an event that has occurred in the agent. The EFD also specifies the conditions under 
which such a notification is to be sent and the IP address of the manager to which the notification is to be sent. All 
standard SNMP traps are sent to the managers UDP port 162. Most management platforms support this mechanism. 
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The Events Group stores event descriptions in a table. Each row in the table corresponds to an event that the agent is to 
generate. The event description in that table specifies when the agent is to generate the event, i.e. because a MIB 
variable has crossed a specified threshold, because a state has been changed, etc. 

Once the agent generates an event as specified in the Event table it checks the EFD Table to find an EFD that matches 
that event and specifies what kind of notification is to be generated and to which manager that notification is to be sent. 
The match is performed based on event characteristics such as event type etc. 

The EFDs in the EFD Table are controlled by three state/status variables, the administrative state, the operational state, 
and the availability status. If the administrative state is not unlocked or the operational state is not enabled or the 
availability status is not available, the EFD is inactive (that means it is ignored by the agent). The manager sets the 
administrative and operational states. The availability status is set as a result of an automatic scheduling function that is 
also associated with the EFD and specified in the EFD table. This scheduling function includes specifications of a daily 
start and stop time and a weekly mask specifying when the EFD changes availability status from off-duty to available. 

Figure 6 illustrates the MIB tree of the Simulcrypt Events Module (SEM): 
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semMIBObjects 

M 



sem Event 
*.1.1 



semEfd 
M.2 



semEventTable 
*. 1.1.1 



semEfdTable 
M.2.1 



semMIB 
1.3.6.1.4.1.2696.1.2 

I 



JZ 



sem M I BConform ance 
*.2 

I 



semCompliances 
*.2.1 



semECMGCompliance 
*.2.1.1 



semEmOrPdCompliance 
*.2.1.2 



semCpsigCompliance 
*.2.1.3 



semCsigCompliance 
*.2.1.4 



semMIBNotificationPrefix 

*.3 



semGroups 
*.2.2 



semMandatoryNotifications 
*.2.2.1 



semThresholdEventGroup 
*.2.2.3 



semStateChangeEventGroup 
*.2.2.5 



sem ValueChangeEventG roup 
*.2.2.7 



semThresholdEfdGroup 
*.2.2.9 



semStateChangeEfdGroup 
*.2.2.11 



semValueChangeEfdGroup 
*.2.2.13 



semMIBNotifications 
*.3.0 



semOptionalNotifications 
*. 2.2.2 



semThresholdEventOptGroup 
*. 2.2.4 



semStateChangeEventOptGroup 
*.2.2.6 



semEventAlarm 
*.3.0.1 



semEventStateChange 
*.3.0.2 



sem EventObjectValueChange 
*.3.0.3 



semValueChangeEventOptGroup 
*.2.2.8 



semThresholdEfdOptGroup 
*.2.2.10 



semStateChangeEfdOptGroup 
*.2.2.12 



semValueChangeEfdOptGroup 
*.2.2.14 



Figure 6: Simulcrypt Events Module SEM 
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7.2.4.1 Event Group 

This group consists of event configuration information defining the types of events that the agent shall generate. 

Table 7: CIM - SEM (P)SIG Group - Event Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
IVIanager 
Maximum 

Access Rig lit 


semEventName 


bslbf/ the unique name of the 
target event, EntryName 
(SNMP) 


provides a unique identification 
of an event 


read-create 


semEventAdminState 


enumerated/administrative 
state of a table row, 
enumerated type (ITU-T 
Recommendation X.731 [8]) 


enables concurrency control 
between multiple management 
entities 


read-create 


semEventAlarmStatus 


enumerated/alarm status of an 
event, enumerated type (ITU-T 
Recommendation X.731 [8]) 


enables event monitoring and 
clearing 


read-create 


semEventType 


enumerated/indicates the type 

of event, enumerated type 

(ITU-T 

Recommendation X.734 [10]) 


enables differentiation 
between distinct event types 


read-create 


semEventText 


bslbf/a description of an 
event's function and use, 
ASCII string of maximum 256 
characters 


enables textual description of 
an event for human readers 


read-create 


semEventChangedObjectId 


bslbf/the object identifier of the 
IVIIB object to check and see if 
the event should fire, OBJECT 
IDENTIFIER (SNMP) 


enables association of MIB 
objects with events 


read-create 


semEventToStateChange 


4 uimsbf/if 

SemEventChangedObjectId is 
a state/status variable this 
variable identifies the state 
that causes the event to be 
generated 


enables association of events 
with state/status variables 


read-create 


semEventRisingThreshold 


4 uimsbf/if 

SemEventChangedObjectId is 
a threshold variable this 
variable indicates the 
threshold value to check 
against; if the value of 
SemEventChangedObjectId is 
greater than or equal an event 
is generated; 32-bit unsigned 
integer 


enables association of events 
with threshold variables 


read-create 


semEventFallingThreshold 


4 uimsbf/if 

SemEventChangedObjectId is 
a threshold variable this 
variable indicates the 
threshold value to check 
against; if the value of 
SemEventChangedObjectId is 
less than or equal an event is 
generated 


enables association of events 
with threshold variables 


read-create 


semEventProbableCause 


enumerated/defines further 
probable cause for the last 
event of this type, enumerated 
type (ITU-T 

Recommendation X.734 [10] 
101) 


enables differentiation 
between event causes 


read 


semEventPerceivedSeverity 


enumerated/defines the 
perceived severity of the last 
event of this type, enumerated 
type (ITU-T 
Recommendation X.734 [10]) 


enables differentiation of event 
severity level 


read 
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Object 


Size/Description 


Object Justification 


Head-end/ CA 
IVIanager 
Maximum 

Access Rig lit 


SemEventTrendlndication 


enumerated/indicates the 
trend of the last event of this 
type, enumerated type (ITU-T 
Recommendation X.734 [10]) 


enables the indication of the 
event trend, i.e. more/less 
severe 


read 


semEventBackedUpStatus 


enumerated/indicates the 
backed up status of the object 
causing the event, enumerated 
type (ITU-T 
Recommendation X.731 [8]) 


enables identification of 
backed up objects 


read-create 


semEventBackedUpObject 


bslbf/if the backed up status is 
backedUp this variable 
contains the object identifier of 
the back up object, OBJECT 
IDENTIFIER (SNMP) 


enables specification of back 
up objects 


read-create 


semEventSpecificProblems 


bslbf/identifies the object 
responsible for the problem, 
OBJECT IDENTIFIER (SNMP) 


enables specification of 
specific problems 


read-create 


semEventFrequency 


4 uimsbf/identifies the number 
of seconds to wait between 
event frequency checks, 32-bit 
unsigned integer 


enables event throtelling 


read-create 


semEventSensitivity 


enumerated/identifies whether 
the event is level or edge 
sensitive. Enumerated 


enables two different types of 
event generation mechanisms: 
whenever a threshold is 
crossed and periodically as 
long as a threshold has been 
crossed 


read-create 


semEventStatus 


enumerated/status variable for 
synchronizing row 
creation/deletion between 
management entities, 
RowStatus (SNIVIP) 


enables synchronization of row 
creation/deletion 


read-create 



7.2.4.2 



Event Forwarding Discriminator (EFD) Group 



This group consists of EFD configuration information defining what types of events an EFD will transform into 
notifications, at what times of day it will do so, and to which managers it will send the notifications to. An EFD 
generates a notification if it is unlocked (administrative state), enabled (operational state) and available (availability 
status) and if all of the specified discriminators are true, i.e. if semEfdDiscriminatedTypes is specified then the type 
indicated has to match the type of the event for a notification to be generated. If multiple discriminators are specified by 
a single EFD then all have to be matched (i.e. logical AND) before a notification is generated. A not specified 
discriminator in an EFD is always TRUE. A single event can match multiple EFDs and generate multiple notifications if 
so specified by the semEfdOr variable. 

The table is indexed by the event name (semEfdName) and the target address of the management entity, which is to 
receive the notification (semEfdTarget). 
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Table 8: CIM - SEM (P)SIG Group - EFD Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
IVIanager 
Maximum 

Access Right 


semEfdName 


bslbf/the unique name of the 
EFD, EntryName (SNMP) 


provides a unique identification 
of an EFD 


read-create 


semEfdAdminState 


enumerated/administrative 
state of a table row, 
enumerated type (ITU-T 
Recommendation X.731 [8]) 


enables concurrency control 
between multiple management 
entities 


read-create 


semEfdOperState 


enumerated/operational state 

of an EFD, enumerated type 

(ITU-T 

Recommendation X.731 [8]) 


enables the indication of the 
current operation state 


read-create 


semEfdAvailStatus 


enumerated/refelects the 
scheduling of the EFD, 
enumerated type (ITU-T 
Recommendation X.731 [8]) 


enables scheduling 


read 


semEfdStartTime 


bslbf/defines the date and time 
at which an unlocked and 
enabled EFD starts 
functioning, i.e. changes the 
availability status from offDuty 
to available, DateAndTime 
(SNMP) 


enables the scheduling of 
EFDs 


read-create 


semEfdStopTime 


bslbf/defines the date and time 
at which an unlocked and 
enabled EFD stops 
functioning, i.e. changes its 
availability status from 
available to offDuty, 
DateAndTime (SNMP) 


same 


read-create 


semEfdDailyStartTime 


bslbf/defines the daily start 
time at which an unlocked and 
enabled EFD starts 
functioning, i.e. changes its 
availability status from offDuty 
to available, TimeTicks 
(SNMP) 


enables daily scheduling of 
EFDs 


read-create 


semEfdDailyStopTime 


bslbf/defines the daily stop 
time at which an unlocked and 
enabled EFD stops 
functioning, i.e. changes its 
availability status from 
available to offDuty, TimeTicks 
(SNMP) 


same 


read-create 


semEfdWeeklyMask 


1 uimsbf/defines the weekly 
schedule at which an unlocked 
and enabled EFD starts 
functioning, an octet string of 
1 octet 


enables weekly scheduling 


read-create 


semEfdTypes 


enumerated/the event type 
that this EFD may generate 
notifications for, enumerated 
type (ITU-T 
Recommendation X.734 [10]) 


enables an EFD to be 
specialized for a particular 
event type 


read-create 


semEfdCause 


enumerated/the probable 
cause that this EFD may 
generate notifications for, 
enumerated type (ITU-T 
Recommendation X.734 [10] 


enables an EFD to be 
specialized by probable cause 


read-create 


semEfdSeverity 


enumerated/the perceived 
severity that this EFD may 
generate notifications for, 
enumerated type (ITU-T 
Recommendation X.734 [10]) 


enables an EFD to be 
specialized by severity 


read-create 
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Object 


Size/Description 


Object Justification 


Head-end/ CA 
IVIanager 
Maximum 

Access Rig lit 


semEfdSpecificProblems 


bslbf/the identifier of the object 
that may cause the generation 
of a notification by this EFD, 
OBJECT IDENTIFIER (SNMP) 


enables an EFD to be 
specialized by event causing 
Object 


read-create 


semEfdTrendlndication 


enumerated/identifies the 
event trend that will cause a 
notification to be generated, 
enumerated type (ITU-T 
Recommendation X.734 [10]) 


enables an EFD to be 
specialized by event trend 


read-create 


semEfdChangedObjectId 


bslbf/identifies the object 
whose value change shall 
cause the generation of a 
notification, OBJECT 
IDENTIFIER (SNMP) 


enables an EFD to be 
specialized by value change of 
an object 


read-create 


semEfdToStateChange 


4 uimsbf/the to state of the 
object that may cause the 
generation of a notification by 
this EFD 


enables an EFD to be 
specialized by a state value 


read-create 


semEfdNotification 


bslbf/identifies the notification 
object identifier to be 
generated if conditions are 
met, OBJECT IDENTIFIER 
(SNMP) 


enables the association of a 
notification type with an EFD 


read-create 


semEfdOr 


enumerated/identifies whether 
the EFD table shall be 
searched further for other 
possible matches and further 
possible notification 
generation, enumerated 


enables multiple notifications 
to be generated by an event 


read-create 


semEfdTarget 


bslbf/the IP address of the 
management entity to receive 
the notification if generated, 
IpAddress (SNMP) 


enables the specification of the 
target management entity for 
the notifications generated by 
the EFD 


read-create 


semEfdText 


bslbf/a description of an 
event's function and use, 
ASCII string of maximum 
256 characters 


enables textual description of 
an EFD for human readers 


read-create 


semEfdStatus 


enumerated/status variable for 
synchronizing row 
creation/deletion between 
management entities, 
RowStatus (SNMP) 


enables syncronization of row 
creation/deletion 


read-create 



7.2.4.3 



Event Notification Group 



This group defines three types of notifications which an agent can send to a manager. These are an alarm, a state change 
notification, and a value change notification. Each EFD specifies what type of notification is to be sent for an event that 
has occurred in the agent. The EFD also specifies the conditions under which such a notification is to be sent and the IP 
address of the manager to which the notification is to be sent. All standard SNMP traps are sent to the managers UDP 
port 162. Most management platforms support this mechanism. 
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The first notification type that can be generated is a semEventAlarm, which carries in addition to the standard SNMPv2 
notification parameters the following objects from the events table: 

semEventName; 

semEventType; 

semEventProbableCause; 

semEventSpecificProblems; 

semEventPerceivedSeverity; 

semEventTrendlndication; 

semEventText. 

The second notification type that can be generated is a semEventStateChange, which carries in addition to the standard 
SNMPv2 notification parameters the following objects from the events table: 

semEventName; 

semEventStateChange; 

semEventChangedObjectld. 

The third notification type that can be generated is a semEventObjectValueChange, which carries in addition to the 
standard SNMPv2 notification parameters the following objects from the events table: 

semEventName; 

semEventChangedObjectld. 

7.2.4.4 Conformance Requirements 

The following table summarizes the conformance requirements for management entities implementing the Simulcrypt 
Events Module (SEM). 
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Table 9: CIM - SEM Conformance Requirements 



Common Information 


Management Entity Hosting 


Management Entity Hosting 


Management Entity Hosting 


Management Entity Hosting 


Management Entity Hosting 


Model- Simulcrypt 


or Representing an ECMG 


or Representing an EMMG 


or Representing a PDG 


or Representing a CPSIG 


or Representing a CSIG 


Events Module Group 






















mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


Events Group - 


name, type. 


backed up. 


name, type. 


backed up. 


name, type. 


backed up. 


name, type. 


backed up. 


name, type. 


backed up. 


threshold events 


text, object-id. 


back up-id. 


text, object-id. 


back up-id. 


text, object-id. 


back up-id. 


text, object-id. 


back up-id. 


text, object-id. 


back up-id. 




thresholds. 


specific 


thresholds. 


specific 


thresholds. 


specific 


thresholds. 


specific 


thresholds. 


specific 




cause. 


problems, 


cause. 


problems. 


cause. 


problems. 


cause. 


problems, 


cause. 


problems. 




severity, trend. 


sensitivity. 


severity, trend. 


sensitivity. 


severity, trend. 


sensitivity. 


severity, trend. 


sensitivity. 


severity, trend. 


sensitivity. 




frequency. 


alarm status 


frequency. 


alarm status 


frequency. 


alarm status 


frequency. 


alarm status 


frequency. 


alarm status 




status, admin 




status, admin 




status, admin 




status, admin 




status, admin 






state 




state 




state 




state 




state 




Events Group - state 


name, type. 


cause. 


name, type. 


cause. 


name, type. 


cause. 


name, type. 


cause. 


name, type. 


cause. 


change events 


text, object-id. 


severity, trend. 


text, object-id. 


severity, trend. 


text, object-id. 


severity, trend. 


text, object-id. 


severity, trend. 


text, object-id. 


severity, trend, 




to state. 


backed up. 


to state. 


backed up. 


to state. 


backed up. 


to state. 


backed up. 


to state. 


backed up. 




frequency. 


back up-id. 


frequency. 


back up-id. 


frequency. 


back up-id. 


frequency. 


back up-id. 


frequency. 


back up-id. 




status, admin 


specific 


status, admin 


specific 


status, admin 


specific 


status, admin 


specific 


status, admin 


specific 




state 


problems, 
sensitivity, 
alarm status 


state 


problems, 
sensitivity, 
alarm status 


state 


problems, 
sensitivity, 
alarm status 


state 


problems, 
sensitivity, 
alarm status 


state 


problems, 
sensitivity, 
alarm status 


Events Group - value 


name, type. 


cause. 


name, type. 


cause. 


name, type. 


cause. 


name, type. 


cause. 


name, type. 


cause. 


change events 


text, object-id. 


severity, trend. 


text, object-id. 


severity, trend. 


text, object-id. 


severity, trend. 


text, object-id. 


severity, trend. 


text, object-id. 


severity, trend. 




frequency. 


backed up. 


frequency. 


backed up. 


frequency. 


backed up. 


frequency. 


backed up. 


frequency. 


backed up. 




status, admin 


back up-id. 


status, admin 


back up-id. 


status, admin 


back up-id. 


status, admin 


back up-id. 


status, admin 


back up-id. 




state 


specific 
problems, 
sensitivity, 
alarm status 


state 


specific 
problems, 
sensitivity, 
alarm status 


state 


specific 
problems, 
sensitivity, 
alarm status 


state 


specific 
problems, 
sensitivity, 
alarm status 


state 


specific 
problems, 
sensitivity, 
alarm status 


EFD Group - threshold 


name, admin 


start, stop. 


name, admin 


start, stop. 


name, admin 


start, stop. 


name, admin 


start, stop. 


name, admin 


start, stop. 


events 


state, oper 


dstart, dstop. 


state, oper 


dstart, dstop. 


state, oper 


dstart, dstop. 


state, oper 


dstart, dstop. 


state, oper 


dstart, dstop. 




state, avail 


week, specific 


state, avail 


week, specific 


state, avail 


week, specific 


state, avail 


week, specific 


state, avail 


week, specific 




status, types. 


problems, text, 


status, types. 


problems, text. 


status, types. 


problems, text. 


status, types. 


problems, text, 


status, types. 


problems, text. 




cause. 


notification 


cause. 


notification 


cause. 


notification 


cause. 


notification 


cause. 


notification 




severity, trend. 


type 


severity, trend. 


type 


severity, trend. 


type 


severity, trend. 


type 


severity, trend. 


type 




object-id. 




object-id. 




object-id. 




object-id. 




object-id. 






notification. 




notification. 




notification. 




notification. 




notification. 






target, status 




target, status 




target, status 




target, status 




target, status 




EFD Group - state 


name, admin 


start, stop. 


name, admin 


start, stop. 


name, admin 


start, stop. 


name, admin 


start, stop. 


name, admin 


start, stop. 


change events 


state, oper 


dstart, dstop. 


state, oper 


dstart, dstop. 


state, oper 


dstart, dstop. 


state, oper 


dstart, dstop. 


state, oper 


dstart, dstop. 




state, avail 


week, specific 


state, avail 


week, specific 


state, avail 


week, specific 


state, avail 


week, specific 


state, avail 


week, specific 




status, types. 


problems, text, 


status, types. 


problems, text. 


status, types. 


problems, text. 


status, types. 


problems, text, 


status, types. 


problems, text. 




object-id, to 


notification 


object-id, to 


notification 


object-id, to 


notification 


object-id, to 


notification 


object-id, to 


notification 




state. 


type 


state. 


type 


state. 


type 


state. 


type 


state. 


type 




notification. 




notification. 




notification. 




notification. 




notification. 






target, status 




target, status 




target, status 




target, status 




target, status 
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Common Information 

Model- Simulcrypt 
Events Module Group 


Management Entity Hosting 
or Representing an ECMG 


Management Entity Hosting 
or Representing an EMMG 


Management Entity Hosting 
or Representing a PDG 


Management Entity Hosting 
or Representing a CPSIG 


Management Entity Hosting 
or Representing a CSIG 


mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


Events Group - value 
change events 


name, admin 
state, oper 
state, avail 
status, types, 
object-id, 
notification, 
target, status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems, text, 
notification 
type 


name, admin 
state, oper 
state, avail 
status, types, 
object-id, 
notification, 
target, status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems, text, 
notification 
type 


name, admin 
state, oper 
state, avail 
status, types, 
object-id, 
notification, 
target, status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems, text, 
notification 
type 


name, admin 
state, oper 
state, avail 
status, types, 
object-id, 
notification, 
target, status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems, text, 
notification 
type 


name, admin 
state, oper 
state, avail 
status, types, 
object-id, 
notification, 
target, status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems, text, 
notification 
type 


Notifications Group 


alarm 


state change, 
value change 


alarm 


state change, 
value change 


alarm 


state change. 
Value change 


alarm 


state change. 
Value change 


alarm 


state change. 
Value change 
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7.2.5 The Simulcrypt Logs Module (SLM) 



SLM enables managers to configure the types of logs that can be generated by an agent. The mechanism and information 
model used are based on the ITU-T Recommendation X.735 [11] Log Model. 

The log in addition to conceptually storing the logged information determines which information is to be logged. Each 
log contains a discriminator construct, which specifies the characteristics an event shall have in order to be selected for 
logging. SLM consists of the following object groups: 

- Log Control Group: This group defines the types of logs tables the agent is maintaining, their discriminators, the 
log scheduling, etc.; 

The Logs Group: This group defines three logs: the alarm logs, the state change logs, and the object value change 
logs. 

Logs are controlled by the Log Control Table as specified in the ITU-T Recommendation X.735 [11]. Each entry in that 
table associates events with logs and specifies when the event is to be logged in that log. The event is logged if the log 
discriminator holds. That is if the event is of a certain type, if it has been generated by a certain object, if it exceeds a 
certain threshold, etc. The log control entries themselves are controlled by state/status variables, the administrative state, 
the operational state, and the availability status. The manager can set the administrative and operational states. The 
availability status is set by the agent itself based on an automatic log control scheduling mechanism, which specifies the 
times during which the logs are to be made. 

Log Control Table entries also specify log control information and log statistics. 

The three logs defined are defined as tables in which each event is stored as a row. The logs in the alarm log table are 
logs of alarm events that have passed the log control discriminator in the Log Control Table. Similarly the logs in the 
state change log table are logs of state changes. And logs in the object value change table are logs of object value 
changes. 

Figure 7 illustrates the Simulcrypt Logs Module MIB tree. 
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sImMIBObjects 

*.1 



sImLogControl 
M.1 



sIm Log DefinitionTable 
M.1.1 



sImLogControlTable 
M.1.2 



sImMIB 
1.3.6.1.4.1.2696.1.3 

I ~ 



sImLogs 

M.2 



sIm Alarm LogTable 
M.2.1 



sImStateChangeLogTable 
M.2. 2 



slmValueChangeLog Table 
M.2. 3 



slmMIBConformance 
*.2 



slmCompliances 

*.2.1 



slmECMGCompliance 
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*.2.2.1 
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*.2.2.9 



sImValueChangeLogControlOptGroup 
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Figure 7: Simulcrypt Logs Module SLM 
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7.2.5.1 



Log Control Group 



This group defines the types of logs tables the agent is maintaining, their discriminators, the log scheduling, etc. The 
group consists of two tables, the Log Definition Table and the Log Control Table. 

The Log Definition Table is used to define all logs in the system. Each entry consists of an slmLogDefinitionld, which is 
the Log identifier, variables defining the log state, and a specification of the log full action. The table is indexed by the 
logDefinitionName. 

Table 10: CIM - SLM Log Definition Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
IVIanager 
Maximum 

Access Right 


sImLogDefinitionName 


bslbf/the unique name of the Log 
Definition Entry, EntryName 
(SNMP) 


provides a unique identification 
of a Log Definition Entry 


read-create 


SlmLogDefinitionld 


bslbf/the unique log table identifier, 
OBJECT IDENTIFIER (SNMP) 


provides a unique identification 
of Log Tables 


read-create 


sImLogDefinitionAdminState 


enumerated/administrative state of 
a table row, enumerated (ITU-T 
Recommendation X.731 [8]) 


enables concurrency control 
between multiple management 
entities 


read-create 


sImLogDefinitionOperState 


enumerated/operational state of an 
EFD, enumerated (ITU-T 
Recommendation X.731 [8]) 


enables the indication of the 
current operation state 


read-create 


sImLogDefinitionAvailStatus 


enumerated/reflects the scheduling 
of the Log Control entry, 
enumerated (ITU-T 
Recommendation X.731 [8]) 


enables scheduling 


read 


sImLogDefinitionFullAction 


enumerated/defines what action to 
take when the maximum log table 
size has been reached, 
enumerated (ITU-T 
Recommendation X.735 [8]) 


enables control of log full 
action 


read-create 


sImLogDefinitionMaxLogSize 


4 uimsbf/defines the maximum size 
of a log table in number of octets 


enables control of the 
maximum log table size 


read-create 


sImLogDefinitionCurrentLogSize 


4 uimsbf/defines the current log 
table size 


enables monitoring of logtable 
size 


read 


sImLogDefinitionNumberOf Records 


4 uimsbf/specifies the number of 
log records in the log table 


enables monitoring of the log 
table size 


read 



The Log Control Table defines possibly multiple Log Controls for the different Logs. Each Log is identified by the Log 
Definition name. Each Log Control is identified by a Log Control name. The table is indexed by the LogDefinitionName 
and the LogControlName. Each log control consists of scheduling and log filtering information. 
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Table 11 : CIM - SLM Log Control Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
IVIanager 
Maximum 

Access Rig tit 


sImLogDefinitionName 


bslbf/the unique name of the Log 
Definition Entry, EntryName 
(SNMP) 


provides a unique identification 
of a Log Definition Entry 


read-create 


sImLogControlName 


bslbf/tlie unique name of the Log 
Control Entry, EntryName (SNMP) 


provides a unique identification 
of a Log Control Entry 


read-create 


sImLogControlStartTime 


bslbf/defines the date and time at 
which an unlocl<ed and enabled 
Log Control entry starts 
functioning, i.e. changes the 
availability status from offDuty to 
available, DateAndTime (SNMP) 


enables the scheduling of Log 
Controls 


read-create 


sImLogControlStopTime 


bslbf/defines the date and time at 
which an unlocked and enabled 
Log Control entry stops 
functioning, i.e. changes its 
availability status from available to 
OffDuty, DateAndTime (SNMP) 


same 


read-create 


sImLogControlDailyStartTime 


bslbf/defines the daily start time at 
which an unlocked and enabled 
Log Control entry starts 
functioning, i.e. changes its 
availability status from offDuty to 
available, TimeTicks (SNMP) 


enables daily scheduling of log 
control entries 


read-create 


sImLogControlDailyStopTime 


bslbf/defines the daily stop time at 
which an unlocked and enabled 
Log Control entry stops 
functioning, i.e. changes its 
availability status from available to 
OffDuty, TimeTicks (SNMP) 


same 


read-create 


sImLogControlWeeklyMask 


bslbf/defines the weekly schedule 
at which an unlocked and enabled 
Log Control entry starts 
functioning, octet string of length 1 


enables weekly scheduling 


read-create 


sImLogControlTypes 


enumerated/the event type that 

this Log Control entry may 

generate logs for, enumerated 

(ITU-T 

Recommendation X.734 [10]) 


enables a Log Control entry to 
be specialized for a particular 
event type 


read-create 


sImLogControlCause 


enumerated/the probable cause 

that this Log Control entry may 

generate logs for, enumerated 

(ITU-T 

Recommendation X.734 [10]) 


enables an Log Control entry 
to be specialized by probable 
cause 


read-create 


sImLogControlSeverity 


enumerated/the perceived severity 

that this Log Control entry may 

generate logs for, enumerated 

(ITU-T 

Recommendation X.734 [10]) 


enables an Log Control entry 
to be specialized by severity 


read-create 


sImLogControlSpecificProblems 


bslbf/the identifier of the object 
that may cause the generation of a 
log entry by this Log Control entry, 
OBJECT IDENTIFIER (SNMP) 


enables an Log Control entry 
to be specialized by Object 


read-create 


sImLogControlToStateChange 


bslbf/the to state of the object that 
may cause the generation of a log 
entry by this Log Control entry, 
32-bit unsigned integer 


enables an Log Control entry 
to be specialized by a state 
value 


read-create 


sImLogControlTrendlndication 


enumerated/identifies the trend 
that will cause a log entry to be 
made, enumerated (ITU-T 
Recommendation X.734 [10]) 


enables specialization of log 
control based on event trends 


read-create 
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Object 


Size/Description 


Object Justification 


Head-end/ CA 
IVIanager 
Maximum 

Access Right 


sImLogControlChangedObjectId 


bslbf/identifies the object that 
changed value and should be 
logged, OBJECT IDENTIFIER 
(SNMP) 


enables specialization of log 
control based on objects 
causing the event 


read-create 


sImLogControlStatus 


enumerated/status variable for 
synchronizing row 
creation/deletion between 
management entities, RowStatus 
(SNMP) 


enables synchronization of row 
creation/deletion 


read-create 



7.2.5.2 



Logs Group 



The three logs defined are defined as tables in which each event is stored as a row. The logs in the alarm log table are 
logs of alarm events that have passed the log control discriminator in the Log Control Table. Similarly the logs in the 
state change log table are logs of state changes. And logs in the object value change table are logs of object value 
changes. The first table defines logs of alarm events as follows. 

Table 12: CIM - SLM Alarm Log Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 

IVIaximum 
Access Right 


sImAlarmLogName 


bslbf/the unique name of the 
Log Control Entry, EntryName 
(SNMP) 


provides a unique identification 
of the alarm log entry; it is 
identical to the event name 


read 


sImAlarmLogTime 


4 uimsbf/the time at which the 
alarm has been logged, 
TimeTicks (SNMP) 


provides a unique identification 
of Log Tables 


read 


sImAlarmLogText 


bslbf/a textual description of 
the event being logged, ASCII 
string of maximum 
256 characters 


records the event description 


read 


sImAlarmLogType 


enumerated/the event type of 

this log entry, enumerated 

(ITU-T 

Recommendation X.734 [10]) 


records alarm type 


read 


sImAlarmLogCause 


enumerated/the event cause 

of this log entry, enumerated 

(ITU-T 

Recommendation X.734 [10]) 


records event cause 


read 


sImAlarmLogSeverity 


enumerated/the alarm severity 
of the logged event, 
enumerated (ITU-T 
Recommendation X.734 [10]) 


receords event severity 


read 


sImAlarmLogSpecificProblems 


bslbf/the identifier of the object 
that caused the logged event, 
OBJECT IDENTIFIER (SNMP) 


records the id of objects 
causing the event 


read 


sImAlarmLogTrendlndication 


enumerated/the trend of the 
event that has been logged, 
enumerated (ITU-T 
Recommendation X.734 [10]) 


records event trend 


read 


sImAlarmLogChangedObjectId 


bslbf/identifies the object that 
changed value and caused the 
logged event, OBJECT 
IDENTIFIER (SNMP) 


records the id of the object 
causing the event 


read 
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The second table defines logs of state change events as follows. 



Table 13: CIM - SLM State Change Log Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


sImStateChangeLogName 


bslbf/the unique name of the 
Log Control Entry, EntryName 
(SNMP) 


provides a unique identification 
of the log entry; it is identical to 
the event name 


read 


sImStateChangeLogTime 


4 uimsbf/the time at whicli the 
alarm has been logged, 
Timelicks (SNMP) 


provides a unique identification 
of Log Tables 


read 


sImStateChangeLogText 


bslbf/a textual description of 
the event being logged, ASCII 
string of maximum 
256 characters 


records the event description 


read 


sImStateChangeLogToStateChange 


bslbf/the to state change of the 
event being logged, 
enumerated (ITU-T 
Recommendation X.734 [10]) 


records event to state change 


read 


sImStateChangeLogChangedObjectId 


bslbf/identifies the object that 
changed value and caused the 
logged event, OBJECT 
IDENTIFIER (SNMP) 


records the id of the object 
causing the event 


read 



The third table defines logs of value change events as follows. 



Table 14: CIM - SLM Value Change Log Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


sImValueChangeLogName 


bslbf/the unique name of the 
Log Control Entry, EntryName 
(SNMP) 


provides a unique 
identification of the log entry; it 
is identical to the event name 


read 


sImValueChangeLogTime 


4 uimsbf/the time at which the 
alarm has been logged, 
TimeTicks (SNMP) 


provides a unique 
identification of Log Tables 


read 


sImValueChangeLogText 


bslbf/a textual description of 
the event being logged, ASCII 
string of maximum 
256 characters 


records the event description 


read 


sImValueChangeLogChangedObjectId 


bslbf/identifies the object that 
changed value and caused 
the logged event, OBJECT 
IDENTIFIER (SNMP) 


records the id of the object 
causing the event 


read 



7.2.5.3 



Conformance Requirements 



The Simulcrypt Logs Module (SLM) is optional. However if log management is implemented the following 
conformance requirements hold. 
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Table 15: CIM - SLM Conformance Requirements 



Common Information 

Model - CIM Simulcrypt 

Logs Module Group 


Management Entity Hosting 
or Representing an ECMG 


Management Entity Hosting 
or Representing an EMMG/ 


Management Entity Hosting 
or Representing a PDG 


Management Entity Hosting 
or Representing a CPSIG 


Management Entity Hosting 
or Representing a CSIG 


mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


mandatory 


optional 


Log Control Group - 
threshold events 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
cause, 

severity, trend, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
cause, 

severity, trend, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
cause, 

severity, trend, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
cause, 

severity, trend, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
cause, 

severity, trend, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


Log Control Group - state 
change events 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, to 
state, status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, to 
state, status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, to 
state, status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, to 
state, status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, to 
state, status 


start, stop, 
dstart, dstop, 
week, specific 
problems 


Log Control Group - 
value change events 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, 
status 


name, log-id, 
start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems 


admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems 


name, log-id, 
admin state, 
oper state, 
avail status, full 
action, max 
log, number of 
recs, current 
log size, types, 
object-id, 
status 


start, stop, 
dstart, dstop, 
week, cause, 
severity, trend, 
specific 
problems 


Logs Group - alarm logs 


name, time, 
text, type, 
object-id 


severity, 

problems, 

trend 


name, time, 
text, type, 
object-id 


severity, 

problems, 

trend 


name, time, 
text, type, 
object-id 


severity, 

problems, 

trend 


name, time, 
text, type, 
object-id 


severity, 

problems, 

trend 


name, time, 
text, type, 
object-id 


severity, 

problems, 

trend 


Logs Group - state 
change logs 


name, time, 
text, object-id, 
to state 




name, time, 
text, object-id, 
to state 




name, time, 
text, object-id, 
to state 




name, time, 
text, object-id, 
to state 




name, time, 
text, object-id, 
to state 




Logs Group - state 
change logs 


name, time, 
text, object-id 




name, time, 
text, object-id 




name, time, 
text, object-id 




name, time, 
text, object-id 




name, time, 
text, object-id 
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7.3 CAS component monitoring and configuration 

Monitoring and configuration of CAS components is accomplished through the Simulcrypt Identification Module (SIM). 
SIM contains version information of the management software as well as Simulcrypt component identification, 
configuration, and status information. Its primary purpose is to provide uniform Simulcrypt component configuration 
and status information across all Simulcrypt elements of a Conditional Access System (Note that this is not the only 
purpose of SIM as it also facilitates the transaction based C(P)SI/(P)SI interface). 

If a management system is implemented, a Simulcrypt CA component needs to implement only those SIM objects, 
which are required for that component type by the SIMF. If a particular object is not supported by the management 
entity of the Simulcrypt CA component (i.e. the SNMP agent) the standard SNMP error code noSuchName is to be 
returned. 

Several totals listed below, mostly concerning number of errors, refer to the total since the agent has started; other totals, 
mostly concerning number of streams, channels, etc. . ., refer to current values. All bslbf and uimsbf units referred to 
below are in byte units. 

The module can be extended by proprietary objects and groups as needed for specific DVB Simulcrypt Integrated 
Management Systems. SIM consists of the following object groups. All access rights can be further restricted by 
individual MIB views if so desired in particular implementations. 
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simldent 

M.1 



simMIB 
1.3.6.1.4.1.2696.1.1 



simMIBObjects 
*.1 



simECMG 
M.2 



simEcmgTable 
M.2.1 



simEcmgCTable 
M.2.2 



simEcmgSTable 
M.2.3 



simEMMG 
M.3 



simEmOrPdTable 
M.3.1 



simEmOrPdLapTable 
M.3. 2 



simEmOrPdLapGTable 
M.3.3 



simEmOrPdCTable 
M.3.4 



simEmOrPdSTable 
M.3.5 



simCPSI 

M.4 



simCpsig Table 
M.4.1 



simCpsigCTable 
*;1.4.2 



simCpsigStream Table 
M.4.3 



simPSI 
M.5 



simPsigTable 
M.5.1 



Sim PsigConfig Table 
M.S. 2 



sImPsigEcmTrTable 
M.5.3 



sImPsigFlowTrTable 
M.5.4 



sImPsigEvntTrTable 
M.5.5 



simPslgDesclnsTable 
M.5.6 



simMIBConformance 
*.2 



sImCompliances 
*.2.1 



simEcmgCompliance 
*.2.1.1 



simEmOrPdCompliance 
*.2.1.2 



simCpsigCompliance 
*.2.1.3 



simPslgCompliance 
*.2.1.4 



simPslgDesclnsDescTable 
M.5.7 



sImPslgTblProvTable 
M.5.8 



simPslgPIDProvTable 
M.5.9 



sImGroups 
*.2.2 



Sim IdentG roup 
*.2.2.1 



simEcmgGroup 
*.2.2.2 



simEmOrPdGroup 
*.2.2.3 



simEmOrPdLapGroup 
*.2.2.4 



simCpsigGroup 
*.2.2.5 



simPsigGroup 
*.2.2.6 



Figure 8: Simulcrypt Information IVIodule SIIUI 
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7.3.1 Ident Group 

This group is used for software configuration management of all Simulcrypt components and includes the following 
objects. 

Table 16: CIM - Simulcrypt Identification Module 



Object 


Size/Description 


Object Justification 


IVIaximum 
Access Right 


simSoftwareVersion 


80 bslbf/ASCII string of 
software version 


to facilitate software 
configuration management 


read 


simMibVersion 


80 bslbf/ASCII string of IVIIB 
version 


same 


read 


simMibPrivateVersion 


80 bslbf/ASCII string of private 
IVIIB version 


same 


read 


simAgentVersion 


80 bslbf/ASCII string of agent 
version 


same 


read 



7.3.2 ECM Generator Group 

This group is used for configuration management and status monitoring of ECM Generators. It identifies each one of the 
ECM Generators by the IP Address and TCP Port Number. It associates Super_CAS_ids, ECM_channel_ids, and 
ECM_stream_ids with ECM Generators. It also associates status information and statistics with channels and streams. 
The ECM Generator Group consists of three conceptual tables. 

The first table is the interconnection table and is used for the Head-end Network Manager to query the IP addresses and 
the port number to be used by an SCS to create a channel. It is indexed by a unique Ecmglndex which is an integer 
assigned by the ECMG agent. 

Table 17: CIM - SIM ECMG Group - Interconnection Table 



Object 


Size/Description 


Object Justification 


IVIaximum 
Access Right 


simEcmglndex 


2 uimsbf/ unique index of the table row 


allows interconnection 
management 


read 


simEcmglpAddress 


octet string of 4 octets/ 
IP address of the ECMG 


same 


read 


simEcmglcpPort 


2 uimsbf/TCP port number of the 
ECMG 


same 


read 


simEcmgSuCasId 


4 uimsbf/Super Cas id 


same 


read 


simEcmgChannels 


2 uimsbf/total number of channels this 
ECMG is currently maintaining 


same 


read 


simEcmgCwPrs 


4 uimsbf/total number of CW 
Provisioning requests received by this 
ECMG 


statistic 


read 


simEcmgErrs 


4 uimsbf/total number of 
communications errors for this ECMG 


same 


read 


simEcmgTargetCpsig 


4 uimsbf/index into the C{P)SIG table 
identifying the C{P)SIG associated with 
this ECMG 


interconnection management 


read 


simEcmgCalVlib 


bisb/pointer to a provider proprietary 
Ecmg MIB (like ifSpecific in the 
interfaces group of MIB II) 


enables extension of ECMG 
MIB by proprietary modules 


read 
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The second ECMG table is used for monitoring channel information. It is indexed by the Ecmglndex and the Channelld. 

Table 18: CIM - SIM ECMG Group - Channel Table 



Object 


Size/Description 


Object Justification 


IVIaximum 
Access Right 


simEcmglndex 


2 uimsbf/unique index of the table row 


enables head-end or CAS 
network manager to monitor 
the status of individual 
channels and streams 


read 


simEcmgChannelld 


2 uimsbf/identifier of a channel 


same 


read 


simEcmgScslpAddress 


octet string of 4 octets/IP address of the 
SCS 


same 


read 


simEcmgScsTcpPort 


2 uimsbf/TCP port number of the SCS 


same 


read 


simEcmgCStreams 


2 uimsbf/total number of streams this 
ECIVIG is currently maintaining on this 
channel 


same 


read 


simEcmgCCwPrs 


4 uimsbf/total number of CW Provisioning 
requests this EClVI has received on this 
channel 


same 


read 


simEcmgCErrs 


4 uimsbf/total number of error messages 
on this channel 


same 


read 



The third table is used for monitoring stream information. It is indexed by the Ecmglndex, the Channelld, and the 
Streamld. 

Table 19: CIM - SIM ECMG Group - Stream Table 



Object 


Size/Description 


Object Justification 


IVIaximum 
Access Right 


simEcmglndex 


2 uimsbf/unique index of the table row 


enables head-end or CAS 
network manager to monitor 
the status of individual 
channels and streams 


read 


SimEcmgChannelld 


2 uimsbf/identifier of a channel 


same 


read 


simEcmgStreamId 


2 uimsbf/identifier of a stream 


same 


read 


simEcmgEcmId 


2 uimsbf/identifier of EClVI stream 


assigned by the head-end to 
uniquely identify each ECM 
stream 




simEcmgSLastCp 


4 uimsbf/last crypto period processed for this 
stream 


enables head-end or CAS 
network manager to monitor 
the status of individual 
channels and streams 


read 


simEcmgSCwPrs 


4 uimsbf/total number of CW Provisioning 
requests this ECMG has received on this 
stream 


same 


read 


simEcmgSErrs 


4 uimsbf/total number of error messages for 
this ECIVIG on this Stream 


same 


read 



7.3.3 EMMG/PDG Group 



This group is used for management of EMM/PD Generators. It identifies each one of the EMM/PD Generators by the IP 
Address and TCP/UDP Port Number. It also associates client_ids, data_channel_ids, and data_stream_ids with 
EMM/PD Generators. It also associates status information and statistics with streams. The EMMG/PDG Generator 
Group consists of five conceptual tables. 

The first table is used for information relevant to EMMG/PDG and is indexed by a unique EmOrPdIndex, which is 
assigned by the EMMG/PDG agent. 
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Table 20: CIM - SIM EMMG/PDG Group - EMMG/PDG Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


si mEmOrPd Index 


2 uimsbf/unique index of the table row 


provides a unique identification 
of a row 


read 


simEmOrPdDataType 


as defined in the DVB Simulcrypt Spec 


indicates to network managers 
whether this is an EMMG or a 
PDG 


read 


simEmOrPdClientId 


4 uimsbf/ClientID 


identifies the client 


read 


simEmOrPdCommCapability 


Enumerated/TCP or UDP or both 


indicates the EMMG/PDG 
communications capability 


read 


simEmOrPdErrs 


4 uimsbf/total number of 
communications errors for this 
EMMG/PDG 


error statistic 


read 


simEmOrPdTargetCpsig 


4 uimsbf/index into the G(P)SIG table 
identifying the C{P)SIG associated with 
this EMMG/PDG 


interconnection management 


read 


simEmOrPdCaMib 


bslbf/pointer to CA provider proprietary 
MIB 


enables custom MIB 
extensions 


read 



The second table is used for configuration of EMMG/PDG. It is uniquely indexed by the EmOrPdLapIndex, which is a 
globally assigned quantity (with respect to the head-end) and associates globally assigned Logical Access Points (LAPs) 
with mux ports. 

Table 21 : CIM - SIM EMMG/PDG Group - Logical Access Point Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


simEmOrPdLaplndex 


2 uimsbf/global unique Logical 
Access Point (LAP) identifier 


enables the association of a 
global logical identifier with a 
mux IP address and port 


read-create 


simEmOrPdAdminState 


enumerated (ITU-T 
Recommendation X.734 [10])/the 
administrative state of a table row 


used to control concurrent 
access to writeable objects as 
defined in ITU-T 
Recommendation X.734 [10] 


read-create 


simEmOrPdLapGommType 


enumerated/TCP or UDP 


defines communications type 


read-create 


simEmOrPdLapMuxIpAddress 


octet string of 4 octets/IP address of 
the Mux 


identifies the mux's IP address 


read-create 


simEmOrPdLapMuxPort 


2 uimsbf/TCP/UDP port of the Mux 


identifies the mux's port 


read-create 


simEmOrPdLapStatus 


enumerated/row status of the entry, 
RowStatus (SNMP) 


used to manage the 
creation/deletion of rows in a 
table 


read-create 
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The third table is also used for configuration of EMMG/PDG. It associates LAP Groups and LAPs and is uniquely 
indexed by the EmOrPdLapGroup, and EmOrPdLapIndex. This association permits a manager to configure an 
EMMG/PDG to service multiple multiplexers and/or multiple multiplexer ports. 

Table 22: CIM - SIM EMMG/PDG Group - Logical Access Point Group Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


simEmOrPdLapGroup 


2 uimsbf/not-unique identifier 
associating ElVIIVIGs to ElVIIVI 
populations 


enables the establishment of 
multiple channels by the 
EIVIMG based on LapGroup 


read-create 


simEmOrPdLaplndex 


2 uimsbf/global unique Logical 
Access Point (LAP) identifier 


enables the association of a 
global logical identifier with a 
mux IP address and port 


read-create 


simEmOrPdLapGAdminState 


enumerated (ITU-T 
Recommendation X.734 [10])/the 
administrative state of a table row 


used to control concurrent 
access to writeable objects as 
defined in ITU-T 
Recommendation X.734 [10] 


read-create 


simEmOrPdLapGStatus 


enumerated/row status of the entry, 
RowStatus (SNMP) 


used to manage the 
creation/deletion of rows in a 
table 


read-create 



The fourth table is used for channel related monitoring information. The table is indexed by the EmOrPdIndex, 
EmOrPdLapIndex, and channel_id. 

Table 23: CIM - SIM EMMG/PDG Group - Channel Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


simEmOrPdIndex 


2 uimsbf/unique index of the EIVIMG/PDG 


identifies the EIVIMG/PDG 


read 


SimEmOrPdLaplndex 


2 uimsbf/logical global unique identifier 


enables the association of a 
global logical identifier with a 
mux IP address and port 


read 


simEmOrPdChannelid 


2 uimsbf/identifier of a channel 


identifies channel and enables 
monitoring of it. 


read 


simEmOrPdCommType 


enumerated/TCP or UDP 


defines the communications 
type for the channel (TCP or 
UDP) 


read-create 


simEmOrPdClpAddress 


octet string of 4 octets/IP address 


used with mux Ip address and 
port number to identify the 
TCP connection used for 
access of MIB II. 


read 


simEmOrPdCPort 


2 uimsbf/TCP/UDP port number 


same 


read 


simEmOrPdOErrs 


2 uimsbf/total number of communications 
errors on this channel 


statistic 


read 
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The fifth table contains stream related information. It is indexed by the simEmOrPdIndex, simEmOrPDLapIndex, and 
simEmOrPdD atald . 

Table 24: CIM - SIM EMMG/PDG Group - Stream Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


SimEmOrPdIndex 


2 uimsbf/unique index of tlie EIVIMG/PDG 


identifies the EIVIMG/PDG 


read 


simEmOrPdLaplndex 


2 uimsbf/logical global unique identifier 


enables the association of a 
global logical identifier with a 
mux IP address and port 


read-create 


simEmOrPdDatald 


2 uimsbf/unique EIVIM or PD stream identifier 


assigned by the head-end to 
uniquely identify the EMM or 
PD stream 


read-create 


simEmOrPdChannelld 


2 uimsbf/identifier of a channel 


enables head-end or CAS 
network manager to monitor 
the status 


read 


simEmOrPdBwidth 


4 uimsbf/bandwidth 


maximum bandwidth allocated 
for this EMM/Private Data 
stream 


read-create 


simEmOrPdStreamId 


2 uimsbf/identifier of a stream 


enables head-end or GAS 
network manager to monitor 
the status 


read 


simEmOrPdSErrs 


4 uimsbf/total number of communications 
errors on this stream 


statistic 


read 


simEmOrPdSBytes 


4 uimsbf/total number of bytes sent by the 
EIVIMG/PDG on this stream 


statistic 


read 



7.3.4 C(P)SIG Group 



This group is used if the (P)SIG Group is not implemented and the stream/channel based protocol between the Custom 
(P)SIG and (P)SIG is implemented. 

The C(P)SIG Group enables management of some aspects of the interaction between the Custom (P)SI Generators 
(C(P)SIG) and the (P)SI generator. It identifies each one of the C(P)SI Generators by the IP Address and TCP Port 
Number. It also associates Super_CAS_ids, Custom_channel_ids, Custom_stream_ids with C(P)SI Generators. It also 
associates status information and statistics with streams. The C(P)SI Generator Group consists of three conceptual 
tables. 

The first table specifies C(P)SIG related information, which is posted by the entity hosting or representing the C(P)SIG. 
A CA/Head-end manager can read this table to communicate TCP/IP information to the (P)SIG, which will establish the 
TCP connection with the C(P)SIG. This table is indexed by a unique Cpsiglndex, which is assigned by the CPSIG agent. 

Table 25: CIM - SIM C(P)SIG Group - C(P)SIG Table 



Object 


Size/Description 


Object Justification 


Maximum 
Access Right 


simCpsiglndex 


2 uimsbf/unique index of the table row 


provides a unique identification 
of a row 


read 


simCpsigSuperCasid 


4 uimsbf/Super GAS id 


client ID 


read 


simCpsigErrs 


4 uimsbf/total number of communications 
errors for this C(P)SIG 


statistic 


read 


simCpsigChannels 


4 uimsbf/total number of channels 
currently maintained by this C(P)SIG 


statistic 


read 


simCpsigCpsigipAddress 


octet string of 4 octets/IP address of the 
C(P)SIG 


the IP address of the C(P)SIG 


read 


simCpsigOpsigPort 


4 uimsbf/TGP port of the C(P)SIG 


the port number of the 
C(P)SIG 


read 


simCpsigCaMlb 


bslbf/pointer to CA provider proprietary 
MIB, OBJECT IDENTIFIER (SNMP) 


enables custom MIB 
extensions 


read 
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The second table is used for channel related monitoring information.The table is indexed by the Cpsiglndex and 
custom_channel_id. 

Table 26: CIM - SIM C(P)SIG Group - Channel Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


simCpsiglndex 


2 uimsbf/unique index of the C(P)SIG 


refers to the index in the first 
table and identifies the 
G(P)SIG 


read 


simCpsigChannelld 


2 uimsbf/identifier of a channel 


identifies channel and enables 
monitoring of it 


read 


simCpsigPsiglpAddress 


octet string of 4 octets/IP address of the 
(P)SIG 


used with the port number and 
C(P)SIG IP address and port 
number can identify the TCP 
connection used for access of 
MIBII. 


read 


simCpsigPsigPort 


2 uimsbf/TCP port number of the (P)SIG 


same 


read 


simCpsigCErrs 


4 uimsbf/total number of communications 
errors on this channel 


statistic 


read 


simCpsigCTstrms 


4 uimsbf/total number of 'transport' streams 
on this channel 


statistic 


read 


simCpsigCSstrms 


4 uimsbf/total number of 'service' streams 
on this channel 


statistic 


read 
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The third table contains 'transport' stream related information. It is indexed by the Cpsiglndex, custom_channel_id, and 
custom_stream_id. 

Table 27: CIM - SIM C(P)SIG Group - Stream Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 
Manager 
Maximum 

Access Right 


simCpsiglndex 


2 uimsbf/unique index of the 
C(P)SIG 


refers to the index in the first 
table and identifies the 
G(P)SIG 


read 


simCpsigChannelld 


2 uimsbf/identifier of a channel 


enables head-end or CAS 
network manager to monitor 
the status of streams on a 
channel 


read 


simCpsigStreamId 


2 uimsbf/identifier of a stream 


same 


read 


simCpsigStreamTStreamId 


2 uimsbf/identifier of a stream 


associates a transport stream 
with the stream 


read 


simCpsigStreamNid 


2 uimsbf/networl< identifier 


associates a network with this 
stream 


read 


simCpsigStreamOnid 


2 uimsbf/original networl< identifier 
of this stream 


associates an original network 
id with the stream 


read 


simCpsigStreamMaxCompTime 


2 uimsbf/maximum time needed to 
process trigger by C(P)SIG 


enables (P)SIG to estimate the 
time between its triggering and 
descriptor insertion by the 
G(P)SIG 


read 


simCpsigStreamTriggerEnable 


2 uimsbf/trigger type definition 


identifies which trigger types 
the C(P)SIG wants 


read 


simCpsigStreamLastTrigger 


2 uimsbf/trigger type 


identifies the type of the last 
trigger processed 


read 


simCpsigStreamLastEventId 


2 uimsbf/event identifier 


identifies the last event for 
which a trigger has been 
processed 


read 


simCpsigStreamLastServiceld 


2 uimsbf/ the service identifier 


identifies the service related to 
the last EGM related trigger 


read 


simCpsigStreamLastEsId 


2 uimsbf/ the elementary stream 
identifier 


identifies the elementary 
stream of the last trigger if the 
EGMs are to be applied 
component wide only and not 
service wide 


read 


simCsigStreamLastEcmPid 


2uimsbf/theECMPID 


identifies the EGM PIDofthe 
last EGM related trigger 


read 


simCpsigStreamErrs 


4 uimsbf/total number of 
communications errors on this 
stream 


statistic 


read 


simCpsigStreamBytes 


4 uimsbf/total number of bytes sent 
by the CPSIG on this stream 


statistic 


read 



7.3.5 Conformance Requirements 



Table 28 summarizes the conformance requirements for management entities implementing the Simulcrypt Identification 
Module (SIM), by group. 



£75/ 



72 



ETSI TS 103 197 VI. 1.1 (2000-06) 



Table 28: CIM - SIM Conformance Requirements 



Common Information 

lUlodel - CIIU1 SImulcrypt 

Identification Module 

Group 


Management 

Entity Hosting 

or Representing 

an ECMG 


Management 

Entity Hosting 

or Representing 

an EMMG 


Management 

Entity Hosting 

or Representing 

aPDG 


Management 

Entity Hosting 

or Representing 

a (P SIG 


Management 

Entity Hosting 

or Representing 

a C(P)SIG 




mndt 


optnl 


mndt 


optnl 


mndt 


optnl 


mndt 


optnl 


mndt 


optnl 


Ident Group 


X 




X 




X 




X 




X 




ECMG Group 


X 




















EMMG/PDG Group (without 
LAPG table) 






X 




X 












EMMG/PDG Group (LAPG 
Table) 








X 




X 










PSIG Group 














X 








CPSI Group 


















X 







8 C(P)SIG ^ (P)SIG interface 

8.1 Overview and Scope 

This section defines the interface that allows one or more CA Systems (CASs) to insert private data into standard 
MPEG-2 PSI and DVB SI tables that are generated by the head-end system. 

The following subsections detail an application protocol model for the C(P)SIG <^ (P)SIG interface and two 
implementation-oriented protocols (connection-oriented protocol and SIMF-based protocol) based on this model. 

Subclause 8.2 presents the model of application protocol defined to support the C(P)SIG <^ (P)SIG interface. 

Subclause 8.3 specifies the C(P)S1G <^ (P)SIG protocol defined on the basis of command/response messages; it 
includes the state machines definition and the messages description. 

Subclause 8.4 specifies the C(P)SIG <^ (P)SIG protocol defined in the network management environment; it includes 
the description of dedicated data structure (MIB) and the definition of rules of operation. 

The head-end and each CAS shall comply with the requirements presented in annex E, clauses E.l and E.2 respectively, 
as well as all specifications documented in the above-described sections. 

As defined in the clause 4 and shown in figure 9, the logical components involved are as follows: 

- PSI Generator (PSIG): the head-end process(es) responsible for generating MPEG-2 PSI (Program Specific 
Information) tables; 

SI Generator (SIG): the head-end process(es) responsible for generating DVB SI (Service Information) tables; 

NOTE: The NIT (Network Information Table) is considered a DVB SI table. 

- Custom PSI Generator (CPSIG): the CA System (CAS) process(es) responsible for generating CAS-specific 
private data for insertion in selected MPEG-2 PSI tables; 

Custom SI Generator (CSIG): the CAS process(es) responsible for generating CAS-specific private data for 
insertion in selected DVB SI tables; 

the generic term (P)SIG refers to a head-end process that serves as a PSIG, an SIG, or both (PSISIG). If the 
head-end supports the C(P)SIG <^ (P)SIG interface, it shall include one or more (P)SIG; 

the generic term C(P)SIG refers to a head-end process that serves as a CPSIG, a CSIG, or both (CPSISIG). Each 
CAS may (optionally) include one or more C(P)SIG. 

This section defines the interface between the C(P)SIG and the (P)SIG. 
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Table 29: Values of (P)SIG_type parameter 



(P)SIG type values 


C(P)SIG or (P)SIG processes 


0x01 
0x02 
0x03 


PSIG 

SIG 

PSISIG 


0x04 
0x08 
OxOC 


CPSIG 

CSIG 

CPSISIG 


other values 


DVB reserved 



C(P)SIG (CAS side) 



(P)SIG (Head-end side) 



CPSISIG 



CPSIG 




CSIG 



CPSIG 



CSIG 




Figure 9: Possible logical architectures of C(P)SIG and (P)SIG 

8.1 .1 Note on commercial agreements 

Certain aspects of the C(P)SIG <^ (P)SIG interface fall outside the scope of the present document, and shall be decided 
by commercial agreements. One such example is the set of non-mandatory PSI and SI tables generated by a (P)SIG. All 
such aspects of this interface are indicated in the text. 

8.1 .2 Note on the PDG ^ MUX Interface 

A CAS may also create private data in the form of private sections that comply with MPEG-2 and DVB section syntax. 
The PDG <^ MUX interface in clause 6 should be used to insert such private sections. 

8.2 Application protocol model 

8.2.1 Overview of the C(P)SIG ^ (P)SIG Application Protocol 

The C(P)SIG<t^(P)SIG Application Protocol includes and defines the following five transaction types: 

Trigger Transactions: Triggers are asynchronous events from the (P)SIG to the C(P)SIG. The (P)SIG first 
informs the C(P)SIG about the types of triggers it supports. The C(P)SIG then informs the (P)SIG which types of 
triggers it wishes to receive. The (P)SIG then communicates these triggers to the C(P)SIG as the corresponding 
events occur; 
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- (P)SI Table Provisioning Transactions: The C(P)SIG requests (P)SI tables from the (P)SIG and the (P)SIG 
communicates those to the C(P)SIG; 

C(P)SIG Descriptor Insert Transactions: The C(P)SIG requests that the (P)SIG inserts (P)SI descriptors into the 
transport stream. The (P)SIG informs the C(P)SIG about the success of the insertion; 

Service Change Transactions: The (P)SIG informs the C(P)SIG about a modification in service existence in a 
transport stream (addition of a service to a TS or deletion of a service from a TS); 

PID Provisioning Transactions: The C(P)SIG requests from the (P)SIG the PID value assigned by the head-end 
to a stream (ECM, EMM or private data) identified by a unique identifier which includes the type of the stream, the 
identifier of the CA system and the CA sub-system the stream belongs to, and an unique stream number. 

In the following subsections configurations, topologies and the five different transaction types are defined. The 
transaction type specifications include only the definitions of the data exchanged by the components. The actual data 
exchange mechanisms are transport dependent and are fully defined in the following two clauses. 



8.2.2 Configurations and Topologies 



Figure 10 illustrates the relevant components in a head-end system with a single CA System (CAS) and in a head-end 
system with multiple CASs. In both diagrams, the M-to-N and 1-to-N notation reflects logical associations, not process 
interconnections. 





CAS 


















M N 




HEAD-END SYSTEM 






C(P)SIG (s) 






PSIG (s) 


1 N 


Transport 









































CASl 






C(P)SIG (s) 


N 









M, 



A^ 





CASk 






C(P)SIG (s) 


X' 









HEAD-END SYSTEM 



PSIG (s) 




A^ 



Transport 



Figure 10: Head-end system with single CAS (top) 
and with multiple CASs (bottom) 

The head-end includes the following components: 

one or more transport streams (TSs) that conform to MPEG-2 and DVB specifications. The C(P)SIG <^ (P)SIG 
Interface views each TS, and its data streams, as logical entities. As such, each TS is uniquely identified, per DVB 
SI, by the triple { original_network_id, network_id, transport_stream_id}. The C(P)SIG <=^ (P)SIG interface does not 
deal with physical components (namely MUXes) that generate TSs; 
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one or more (P)SIG components. Each (P)SIG is uniquely identified by its IP address and TCP port number; 

connections between the (P)SIGs and the TSs. The relationship between (P)SIG and TS is 1-to-N: each (P)SIG 
generates standard PSI and/or SI tables for one or more TSs and no TS is served by more than one (P)SIG. 

The head-end shall supply either a PSISIG or a {PSIG+SIG} to serve each TS. 

The present document does not define the physical connection between (P)SIG and TS; it is a matter of head-end 
implementation. 

Each CAS that supports the C(P)SIG <^ (P)SIG Interface includes the following components: 

one or more C(P)SIG components. Each C(P)SIG is uniquely identified by a custom_CAS_id, as well as its IP 
address and TCP port number. 

The relationship between the C(P)SIG(s) of a CAS, and the (P)SIG(s) of the head-end, is M-to-N. Given also the 1-to-N 
relationship of (P)SIG to TS, this means: 

each C(P)SIG may generate CAS-specific private data for zero or more TSs; 

any TS may be served by zero or more C(P)SIGs, as long as said C(P)SIGs and TS are connected to the same 
(P)SIG. 

The components of each CAS are logically independent of each other. Any TS may be served by zero or more C(P)SIGs 
from one or more CASs, as long as said C(P)SIGs and TS are connected to the same (P)SIG. 



8.2.3 Trigger Transaction Type 



The trigger is the means by which a (P)SIG component indicates to a C(P)SIG that a particular event is going to take 
place. 

DVB Simulcrypt has identified the following trigger types: 

Following DVB-event; 
- Future DVB -event; 

ECM stream setup; 

Access criteria change; 

ECM stream closure; 

Flow PID change. 

The Following DVB-event trigger indicates that a new event is going to be broadcast on a given service. 

The Future DVB-event trigger indicates that the head-end has at its disposal some information concerning a future 
event. The moment at which this message is sent is not specified by DVB. 

The ECM stream setup trigger indicates that a new ECM stream is going to be opened. 

The Access criteria change trigger indicates that the access criteria of an existing ECM stream is going to be changed. 

The ECM stream closure trigger indicates that an ECM stream is due for closure. 

The Flow PID change trigger indicates that the PID value of an existing ECM, EMM or private data stream is going to 
be changed. 

With the exception of the Future DVB-event trigger, the time at which the trigger message is sent with respect to the 
corresponding event is computed by the (P)SIG, by subtracting the max_comp_time value from the time at which the 
corresponding event takes place. This lets time for the C(P)SIG to reply with descriptor_insert messages if needed, and 
control the precise timing of the insertion of descriptors. 

For the head-end, the support of the Future DVB-Event is optional. 
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During the channel setup, the (P)SIG indicates what kind of triggers it is able to generate. The C(P)SIG has the 
possibility to subscribe to some trigger types per service. A trigger subscription is on a service basis, meaning, that a 
C(P)SIG can subscribe to different triggers depending on the services: such a trigger subscription can be modified at any 
time. 

The (P)SIG communicates to the C(P)SIG the types of triggers its supports as an octet string of length 4 (triggerjist) 
encoded as bit mask with the meaning given in table 30 if set: 

Table 30: Trigger types 



trigger cause 


trigger list bit # 


trigger type 


DVB reserved 


none 


0x00000000 


following event 


(Isb) 


0x00000001 


future event 


1 


0x00000002 


ECM stream setup 


2 


0x00000004 


access criteria change 


3 


0x00000008 


ECM stream closure 


4 


0x00000010 


flow PID change 


5 


0x00000020 


DVB reserved 


6to15 


0x00000040 to 0x00008000 (powers of 2 only) 


user defined 


16 to 31 (msb) 


0x00010000 to 0x80000000 (powers of 2 only) 


combination of any previous 


any combination 


any value from 0x00000000 to OxFFFFFFFF 



The C(P)SIG communicates to the (P)SIG which triggers it wishes to receive using the same mask. 
The trigger information communicated by the (P)SIG to the C(P)SIG includes the following: 

original network identifier as defined by DVB SI (original_network_id); 

network identifier as defined by DVB SI (network_id); 

transport identifier as defined by DVB SI (transport_stream_id); 

service identifier as defined by DVB SI or the MPEG PAT program_number (service_id); 

trigger type coded the same way as the trigger mask defined above; 

either event related data, ECM related data or flow PID change related data depending on the trigger type. 
Event related data is defined as follows: 

- event identifier as defined in ETSI EN 300 468 [ 1 ] (eventjd); 

event duration in hours, minutes, seconds coded as six 4-bit BCD digits; 

start time of the event in Modified Julian Date (MJD) and Universal Time, Coordinated (UTC) formats. It is 
contained in an octet string of length 5. The MJD is coded in the 16 LSBs followed by six 4-bit BCD digits 
representing UTC; 

- private data which correspond to the event private data. 
ECM related data is coded as follows: 

elementary stream identifier of the elementary stream to which the ECM stream is attached; 

- ECM PID; 

ECM Identifier which corresponds to the ECM channel identifier, the ECM stream identifier, and the Super_CAS 
identifier; 

access criteria. 

Flow-PID change related data is coded as follows: 

flow-type; 

flow-super-CAS-id; 
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flow-id; 
flow-PID. 



8.2.4 Table Provisioning Transaction Type 



The C(P)SIG communicates to the (P)SIG the following information uniquely identifying in a given transport-stream the 
table the C(P)SIG is requesting, according to table 31: 

Original network identifier and transport identifier (original_network_id and transport_stream_id as defined by DVB SI) 
identifying the transport stream carrying the requested table 

Table identifier: 

original network identifier as defined by DVB SI (original_network_id); 

network identifier as defined by DVB SI (network_id); 

transport identifier as defined by DVB SI (transport_stream_id); 

service identifier as defined by DVB SI (service_id) or the MPEG PAT program_number; 

- bouquet identifier as defined by DVB SI (bouquet_id); 

event identifier as defined by DVB SI (event_id); 

segment number in an EIT schedule as defined by DVB SI. 

Table 31 : Table Identifier coding and required parameters 



Table 


Tablejd 


Required parameters 


all tables: identification of the transport stream 
carrying the requested table 


- 


original_network_id 
transport stream id 


PAT 


0x00 


- 


CAT 


0x01 


— 


PMT 


0x02 


service id (MPEG-2 program number) 


NIT actual network 


0x40 


— 


NIT other network 


0x41 


network idother 


BAT 


0x4A 


bouquet id 


SDT actual TS 


0x42 


— 


SDT other TS 


0x46 


original_network_idother 
transport stream idother 


EIT p/f actual TS 


0x4 E 


service id 


EIT p/f other TS 


0x4 F 


original_network_idother 
transport_stream_idother 
service id 


EIT schedule actual TS (whole sub-table) 


0x50 — 0x5F 


service id 


EIT schedule actual TS (single segment) 


0x50 — OxSF 


servicejd 
segment number 


EIT schedule actual TS (single event only) 


0x50 


servicejd 
event id 


EIT schedule other TS (whole sub-table) 


0x60 — 0x6F 


original_network_idother 
transport_stream_idother 
service id 


EIT schedule other TS (single segment) 


0x60 — 0x6F 


original_network_idother 
transport_stream_idother 
servicejd 
segment number 


EIT schedule other TS (single event only) 


0x60 


original_networkJdother 
transport_streamJdother 
servicejd 
event id 
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The C(P)SIG requests either complete PSI tables or SI sub-tables (see ETSI EN 300 468 [1]). As EIT Schedule 
sub-tables may be very large, the protocol optionally allows the C(P)SIG to request only the part of the EIT Schedule 
sub-table that concerns a specific event or a specific segment. In case the request concerns a specific event_id, the value 
of the table_id field shall be set to 0x50 for the events pertaining to the current TS and 0x60 for the events pertaining to 
an EIT other. 

The table requested is supplied by the (P)SIG to the C(P)SIG if available. The communications mechanism is transport 
dependent and specified in the next two Sections. 

8.2.5 Descriptor Insertion Transaction Type 

The C(P)SIG communicates to the (P)SIG the descriptors that the C(P)SIG wants to be inserted in the PSI/SI tables of a 
given transport stream. This includes all the information that the (P)SIG needs to know where and when to insert the 
descriptors. The information depends on the type of descriptor inserted and is specified below: 

original 
network identifier and transport stream identifier (original_network_id and transport_stream_id as defined by DVB 
SI) identifying the transport stream carrying the table where descriptors are to be inserted; 

trigger identifier if related to a previously transmitted trigger; 

insertion delay type which can be either immediate (i.e. no delay) or synchronized with the cause of a trigger if 
the trigger is identified; 

insertion delay: this parameter is significant only if insertion delay type is synchronized in seconds; the delay 
value can be positive in which case it indicates that the synchronization is to happen the delay time after the trigger 
cause, or negative in which case it indicates that the synchronization is to happen the delay time before the cause; 

location identifier, which identifies the table and descriptor, loop if applicable in which the (P)SIG is to insert the 
set of descriptors; 

original network identifier as defined by DVB SI (original_network_id); 

network identifier as defined by DVB SI (network_id); 

transport identifier as defined by DVB SI (transport_stream_id); 

service identifier as defined by DVB SI or the MPEG PAT program_number (service_id); 

- bouquet identifier as defined by DVB SI (bouquet_id); 
event identifier as defined by DVB SI (event_id); 

elementary stream identifier of the elementary stream to which the ecm stream is attached; 

- private data specifier as specified by ETSI EN 300 468 [1] and ETSI ETR 162 [3]; 

descriptor to be inserted. 

The private_data_specifier parameter enables the C(P)SIG to request the insertion of the set of descriptors within the 
scope of a private_data_specifier descriptor (as defined in ETSI EN 300 468 [1]), if supported by the head-end. 

The insertion_delay_type and insertion_delay parameters provide synchronization information. They indicate to the 
(P)SIG when to insert the set of descriptors with respect to the ECM stream modification time or the event start time. 
The insertion_delay parameter indicates the amount of time between the insertion of the table and the insertion of the 
ECMs in the transport stream. If it is positive, it means that the insertion of the table in the transport stream shall occur 
after the start of the ECM broadcast. If negative, it means that the modified PSI/SI table shall be broadcast ahead of the 
ECM modification time in the transport stream. 
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Table 32 indicates, for each MPEG-2 PSI and DVB SI table, which parameters are needed. 

Table 32: Location Identifiers and Required Parameters 



Table 


Locationjd 
value 


Required location parameters 


all tables: identification of the transport 
stream carrying the targetted table 


- 


original_network_id 
transport stream id 


CAT 


0x01 


— 


PMTI'Moop 


0x02 


service id (MPEG-2 program number) 


PMT 2™ loop 


0x03 


service id (l\/IPEG-2 program number) 
ES id 


NIT 1^' loop - actual network 


0x04 


— 


NIT 2™ loop - actual network 


0x05 


original_network_id(2nd loop) 
transport stream id(2ndioop) 


NIT 1^' loop - other network 


0x06 


network idother 


NIT 2™ loop - other network 


0x07 


networkjdother 
original_network_id(2nd loop) 
transport stream id(2ndioop) 


BATI'Moop 


0x08 


bouquet id 


BAT 2™ loop 


0x09 


bouquetjd 

original_network_id(2nd loop) 
transport stream id(2ndioop) 


SDT (actual TS) 


OxOA 


service id 


SDT (other TS) 


OxOB 


original_network_idother 
transport_stream_idother 
service id 


EIT present/following (actual TS) 


OxOC 


servicejd 
event id 


EIT present/following (other TS) 


0x0 D 


original_network_idother 
transport_stream_idother 
servicejd 
event id 


EIT schedule (actual TS) 


0x0 E 


servicejd 
event id 


EIT schedule (other TS) 


0x0 F 


original_networkJdother 
transport_streamJdother 
servicejd 
event id 



The descriptor insertion "location" (PSI/SI table and descriptor loop, if applicable) is unambiguously qualified by the 
locationjd and the location parameters given above. When a given C(P)SIG provides a set of descriptors for insertion, 
that set replaces the previous set at the same location (in the same private_data_specifier context). 

The C(P)SIG can associate the descriptor insertion with a trigger by supplying a trigger Jd parameter. 

8.2.6 Service Change Transaction Type 

The (P)SIG informs the C(P)SIG about a modification in service existence in a transport stream (addition of a service to 
a transport stream or deletion of a service from a transport stream). More sophisticated functions such as servicejd 
change or the move of a service from one transport stream to another transport stream can be achieved by combining 
these two basic addition and deletion functions. The (P)SIG can give as well the scheduled day and time of the service 
change in the transport stream. 

8.2.7 Flow PID Provisioning Transaction Type 

The PID provision functionality is available only in the C(P)SIG <=^ (P)SIG protocol. As used in this section, the word 
"flow" concerns an ECM stream, an EMM stream or a private data stream in a particular transport stream. A (P)SIG can 
provide a C(P)SIG with the PID of a flow by one of these three ways: 

- by explicit request from the C(P)SIG to the (P)SIG: the flow PID provisioning functionality described in this 
section; 
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- by triggering the C(P)SIG when a change of PID occurs in a flow; 

for an ECM stream, by triggering the C(P)SIG when a new ECM stream is created. 

A flow is unambiguously known by the head-end and by the CAS by using its unique identifier defined as the 
combination of: 

the type of the flow: flow_type = ECM, EMM or private data; 

the Super CAS_id this flow belongs to: flow_super_CAS_id; 

an individual number: flow_id; for a flow_super_CAS_id and a flow_type, the flow_id shall be unique. 

Such a combination identifies uniquely a flow across all the Simulcrypt protocols used in a real configuration and across 
all the transport streams generated by the head-end. 

Depending on the type of the flow, its unique identifier is assigned by the head-end (ECM) or by the CAS (EMM, 
private data) when the flow is created. 

When a unique identifier exists in the system, the head-end is assumed to know which flow_PlD value is associated 
with. 

The consequences are that: 

the unique identifier of an ECM flow (absolute reference) is carried in the ECMG protocol in addition to the 
channel_id and stream_id parameters (references relative to the current ECMG-SCS connection); it shall be assigned 
by the head-end and provided to the ECMG at stream setup; 

the unique identifier of an EMM/private data flow (absolute reference) is carried in the EMMG/PDG protocol in 
addition to the channel_id and stream_id parameters (references relative to the current EMMG/PDG-MUX 
connection); it shall be assigned by the EMMG/PDG and provided to the head-end at stream setup; 

in the C(P)S1G protocol, the PID provisioning functionality allows the C(P)S1G to get the flow_PlD value of a 
particular flow identified by its unique identifier; 

- in the C(P)S1G protocol, the flow-PlD-change trigger functionality allows the (P)SIG to trigger the C(P)SIG 
when a change occurs for the flow_PlD value of a particular flow identified by its unique identifier; 

- in the C(P)S1G protocol, the flow-PlD of an ECM stream (i.e., ECM-PID) is given among other ECM related 
parameters by the (P)SIG when the ECM stream is created; 

- it is assumed that a CAS can support internal links between ECMG and C(P)SIG or between EMMG/PDG and 
C(P)SIG to manage consistently the unique identifiers it is concerned by. 

Figure 1 1 depicts this mechanism for ECM stream (in this case ECM_id and flow_id are homonym) and for 
EMM/private data stream (in this case data_id and flow_id are homonym, data_PID and flow_PlD as well). 

In the ECMG protocol, the type of the flow is implicitly ECM; the flow_super_CAS_id is the Super_CAS_id, which is 
implicitly in the channel_id. Hence in this protocol only the flow_id shall be given explicitly. 

In the EMMG/PDG protocol, the type of the flow is given in the data_type parameter (EMM or PDG); the 
flow_super_CAS_id is the client_id, which is implicitly in the channel_id. Hence in this protocol only the flow_id shall 
be given explicitly. 

In the C(P)SIG protocol: 

in the PID-provision function, the three parameters flow_type, flow_super_CAS_id, flow_id shall be given 
explicitly; in particular, the flow_super_CAS_id is not always the custom_CAS_id; 

in the ECM-setup trigger function, the flow_type is implicitly ECM; so both parameters flow_super_CAS_id and 
flow_id shall be given explicitly; in particular, the flow_super_CAS_id it not always the custom_CAS_id; 

in the flow-PID-change trigger function, the three parameters flow_type, flow_super_CAS_id and flow_id shall 
be given explicitly. 
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stream setup 
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PID-provision function 
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NOTE: The flow PID provisioning transaction allows a CAS to receive PID values for particular streams. The CA 
System is responsible for the (possibly undesirable) consequences, when using these PIDs. In particular, 
inserting these PIDs in private data can cause problems when re-multiplexing occurs. 

Figure 11: PID provision mechianism for ECIU! 
and ElVIIVI/private data streams 

8.2.8 Implementation of the C(P)SIG ^ (P)SIG protocol 

The generic C(P)SIG <^ (P)SIG interface defined in the sections above shall be implemented in one of the two 
following ways: 

in a connection-oriented protocol: in this case the implementation shall be compliant with the subclause 8.3; 
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in a SIMF-based protocol: in this case, the implementation shall be compliant with the subclause 8.4. 

8.3 Connection-oriented protocol 

This section specifies the connection-oriented instance of the generic C(P)SIG <^ (P)SIG protocol defined in the 
subclause 8.2. 

In such an implementation the C(P)SIG and (P)SIG processes communicate with each other via a connection-oriented 
protocol. 

8.3.1 Overview of the C(P)SIG -^ (P)SIG connection-oriented protocol 

8.3.1.1 Principles 

In this connection-oriented protocol, the (P)SIG is the client and the C(P)SIG is the server. The (P)SIG has a prior 
knowledge of the mapping between Custom_CAS_id and the IP addresses and port numbers of the C(P)SIG. Once the 
(P)SIG has established a TCP connection with the C(P)SIG, it opens a channel (see subclause 8.3.1.2) dedicated to the 
Custom_CAS_id. Then it opens as many streams (see subclause 8.3.1.3) as transport streams it manages. When a stream 
is open, the C(P)SIG may, for the relevant transport stream, request for PSI and SI tables, be triggered on particular 
conditions and insert private descriptors. 

To achieve this, this connection-oriented protocol offers a set of messages at channel level and stream level, which can 
be used according to a specific state machine. Messages and state machine are described in the following sections. 

The general format of the messages is defined in subclause 4. 4.1. The following points also apply to all 
C(P)SIG <^ (P)SIG messages specified by this connection-oriented protocol: 

depending on their type or their use in the state machine, certain messages may be sent by a (P)SIG only (noted 
"C(P)SIG <(= (P)SIG"), others may be sent by a C(P)SIG only (noted "C(P)SIG => (P)SIG"), the remainder may be 
sent by either (noted "C(P)SIG <^ (P)SIG"). This is clearly indicated in the descriptions that follow; 

a message whose name ends with "_request" shall be answered by the receiver, using the corresponding message 
whose name ends with "_response"; 

all messages include a 16-bit transaction_id, which is used to match messages with their responses. The 
transaction_id is assigned cyclically by the originator of the message (C(P)SIG or (P)SIG), and is unique per 
channel. Values of through 32767 are reserved for C(P)SIG use; the (P)SIG shall use values 32 768 through 
65 535; 

though a real implementation will include time_out management, the present document does not specify a time- 
out for a response, nor the actions (e.g. failure or retry) to be taken if a message is not received within a given time. 
The present document also does not define any specific mechanisms to ensure message delivery other than TCP 
itself. 

8.3.1.2 Channels 

8.3.1 .2.1 Definition and types 

The logical connection between a C(P)SIG and a (P)SIG is comprised of one and only one channel per CAS. There is 
only one channel per TCP connection. 

Since a channel interconnects a single C(P)SIG with a single (P)SIG, any of seven types of channels is possible; refer to 
the leftmost diagram in figure 12. The channel types that can actually be established depend on the respective 
configurations of the CAS and head-end processes. For example, a CPSISIG may be interconnected with a {PSIGh-SIG} 
with either or both of the connections depicted in the rightmost diagram in figure 12. 
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CPSISIG 



r 



CPSIG 




CSIG 

Figure 12: All types of C(P)SIG o (P)SIG channels 

Each channel is identified by a 2-byte custom_channel_id. This value is unique per C(P)SIG (custom_CAS_id). 

8.3.1.2.2 Channel establishment 

The head-end is responsible for establishing all channels at system initialization time, or when a CAS is newly interfaced 
to the head-end. Accordingly, the head-end (and possibly the CAS) shall have prior information of the channels to be 
established, as well as all parameters required for connection. 

This channel information is determined by commercial agreement, per business and technical requirements. The manner 
in which this information is maintained and used is beyond the scope of the present document. 

8.3.1.3 Streams 

8.3.1.3.1 Definition 

As described in subclause 8.3.1.2, a channel connects a C(P)SIG with a (P)SIG. A channel logically connects a C(P)SIG 
with one or more TSs. 

A stream is a logical connection between a C(P)SIG and a (P)SIG, which serves a single TS. As such, a stream 
"belongs" to a channel. Within a channel, the relationship between stream and TS is 1-to-l (or 0-to-l: a TS need not 
have any stream associated with it). Figure 13 illustrates this relationship. 

The primary purpose of a stream is to serve as the logical conduit from a C(P)SIG to a (P)SIG, for the transmission of 
CAS-specific private data in a given TS. At least one stream shall be established, and operational, for a C(P)SIG to 
generate private data in any TS. 

As a stream "belongs" to a channel, and a channel "belongs" to a CAS, a stream cannot convey information pertaining to 
more than one CAS. 

Each stream is identified by a 2-byte custom_stream_id. This value is unique per channel. 

The value of custom_stream_id uniquely identifies a TS. This TS is identified by the same value of custom_stream_id 
across all channels. 
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Figure 13: Stream interconnections (simple example) 

Multiple streams shall be established per channel when the C(P)SIG needs to generate CAS-specific private data in 
more than one TS. Multiple streams corresponding to one TS cannot be configured for other reasons, e.g. performance, 
capacity or redundancy. 

Refer also to annex F for a sample channel and stream configuration for a head-end with two CASs. 



8.3.1.3.2 



Stream establishment 



The head-end is responsible for establishing all streams at system initialization time, or when a CAS is inserted to the 
head-end. Accordingly, the head-end (and possibly the CAS) shall have prior information of the streams to be 
established, as well as all parameters required for connection. 

This stream information is determined by commercial agreement, per business and technical requirements. The manner 
in which this information is maintained and used is beyond the scope of the present document. 



8.3.1.4 



C(P)SIG ^ (P)SIG message lists 



There are two general classes of messages: 

Channel-level messages pertain to the configuration or status of a channel. Their semantic scope is a channel, 
and they do not reference streams or DVB services; 



channel_setup 


0x0301 


C(P)SIG 


<= 


(P)SIG 


channel status 


0x0302 


C(P)SIG 


<=* 


(P)SIG 


channel test 


0x0303 


C(P)SIG 


<=* 


(P)SIG 


channel close 


0x0304 


C(P)SIG 


<= 


(P)SIG 


channel_error 


0x0305 


C(P)SIG 


•t* 


(P)SIG 



Stream-level messages pertain to the configuration or status of a stream, the supply of currently transmitted 
PSI/SI, and to the transmission of CAS-specific private data for insertion in MPEG-2/DVB tables. These messages 
require a channel that is established and operational. Their semantic scope is a stream, a transport stream (TS) or a 
DVB (or MPEG-2) service, depending on the message. 
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stream_setup 


0x031 1 


C(P)SIG 


<= 


(P)SIG 


stream_status 


0x0312 


C(P)SIG 


<=i> 


(P)SIG 


stream_test 


0x0313 


C(P)SIG 


<=i> 


(P)SIG 


stream_close 


0x0314 


G(P)SIG 


<= 


(P)SIG 


stream_close_request 


0x0315 


G(P)SIG 


^ 


(P)SIG 


stream_close_response 


0x0316 


C(P)SIG 


<= 


(P)SIG 


stream_error 


0x0317 


C(P)SIG 


<=i> 


(P)SIG 


stream_service_change 


0x0318 


C(P)SIG 


<= 


(P)SIG 


stream_trigger_enable_request 


0x0319 


C(P)SIG 


^ 


(P)SIG 


stream_trigger_enable_response 


0x031 A 


C(P)SIG 


<^ 


(P)SIG 


trigger 


0x031 B 


C(P)SIG 


<= 


(P)SIG 


table_request 


0x031 C 


C(P)SIG 


^ 


(P)SIG 


table_response 


0x031 D 


C(P)SIG 


<= 


(P)SIG 


descriptor_insert_request 


0x031 E 


C(P)SIG 


^ 


(P)SIG 


descriptor_insert_response 


0x031 F 


C(P)SIG 


<= 


(P)SIG 


PID_provision_request 


0x0320 


C(P)SIG 


^ 


(P)SIG 


PID_provision_response 


0x0321 


C(P)SIG 


<= 


(P)SIG 



All channel-level and stream-level messages shall be supported by all C(P)SIG and (P)SIG processes, with any semantic 
exceptions noted in the present document. 



8.3.1.5 



Protocol state machines definition 



This protocol is based on two state machines. The first state machine defines the transitions associated with each 
channel. The second state machine defines the transitions associated with each stream; this state machine is valid only 
for a channel in the Channel Open state. 

The state machines defines: 

States: A total of eleven states is defined, four for the channel state machine, and seven for the stream state 
machine; 

Transitions: the set of messages that cause changes of state in the state machine. 

The basic functionality of each message is presented in order to understand state machine operation. Precise and detailed 
syntax and semantics of each message are presented in subclause 8.3.2. 

Independence and scalability: all channels in a complete system are mutually independent; the same is true of streams. 
Therefore, both state machines are scalable: concurrent state machines can be launched for each channel and stream in 
the system, whether the head-end is hosting one or multiple CASs. 



8.3.1.6 



Channel state machine 



As described in subclause 8.3.1.2.2, the head-end establishes and maintains one or more channels between (P)SIG and 
C(P)SIG processes. This section presents the channel state machine, which defines the sequence of channel-level 
messages that shall be used to establish and maintain a single channel. 

Channels may be established in any order. In addition, a (P)SIG needs not wait for the establishment of one channel to 
be complete, before commencing the establishment of another channel. Such considerations are out of the scope of the 
present document. 

The channel state machine is found in figure 14. Each state found in this state machine is defined in subclauses 8.3.1.6.1 
to 8.3.1.6.4. 
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Figure 14: C(P)SIG «* (P)SIG channel state machine 



8.3.1.6.1 



Channel Not Open 



This state represents the initiahzation of the channel state machine. At this point, a TCP connection is assumed to be 
established and the channel has either not been initialized, or has been closed. 

- The (P)SIG initializes a channel by sending a channel_setup message to the C(P)SIG on the other end of the 
channel. Channel_setup is the only permissible message in the Channel Not Open state. Parameters of channel_setup 
identify the (P)SIG type (PSISIG, PSIG or SIG) and the kinds of triggers supported by the (P)SIG for the new 
channel. Transmission and receipt of channel_setup move the state machine to the Channel Setting Up state. 

8.3.1 .6.2 Channel Setting Up 

From this state, the C(P)SIG shall respond with either a channel_status or a channel_error message: 

The channel_status message acknowledges successful channel establishment, and that the channel is open. The 
C(P)SIG also indicates, via this message, the maximum number of streams that can be supported on the new channel. 
Transmission and receipt of channel_status move the state machine to the Channel Open state. 

The channel_error message acknowledges that the C(P)SIG could not open the channel, and that the channel 
shall be closed by the (P)SIG. One or more error codes explain the failure. Transmission and receipt of 
Channel error move the state machine to the Channel In Error state. 



8.3.1.6.3 



Channel Open 



This state represents the steady-state operation of the channel state machine. As long as the channel is open and error- 
free, streams may be opened, used and closed, per the stream state machine defined in subclause 8.3.1.7: the stream state 
machine defines the stream-level and data-level messages that can be sent on a stream within the channel, per the state of 
that stream. 
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Four kinds of channel-level messages can be sent while in Channel Open state: 

Either the C(P)SIG or the (P)SIG can send a channel_test message, in order to verify the error-free operation of 
the channel. This does not change the state of the channel state machine; 

If the channel is in an error-free situation, the receiver of the channel_test message shall reply with a 
channel_status message. This does not change the state of the channel state machine. Channel_status may be sent 
only in response to channel_test; 

If the C(P)SIG encounters an unrecoverable channel error at any other time^ it shall send the (P)SIG a 
channel_error message. If the stream has unrecoverable errors, the receiver of the channel_test message shall reply 
with a channel_error message. One or more error codes explain the failure. Transmission and receipt of 
channel_error move the state machine to the Channel In Error state. Channel_error may be sent at any time from the 
Channel Open state; 

If the (P)SIG wants to close the channel for any reason, it shall send the C(P)SIG a channel_close message. 
Receipt of channel_close moves the state machine to the Channel Not Open state. Channel_close may be sent at any 
time from this state. 

Channel_close also causes the immediate closure of all streams open in the channel. 

8.3.1.6.4 Channel In Error 

This temporary and short-lived state is used only to represent the fact that the C(P)SIG has encountered and reported an 
unrecoverable channel error. The (P)SIG shall close the channel: 

The (P)SIG sends a channel_close message to the C(P)SIG. Transmission and receipt of channel_close move the 
state machine to the Channel Not Open state. 

Channel_close also causes the immediate closure of all streams open in the channel. 

8.3.1 .7 Stream state machine 

As described in subclause 8.3.1.3.2, the head-end establishes one or more streams within a channel. This section 
presents the stream state machine, which defines the sequence of stream-level messages that shall be used to establish, 
maintain and use a single stream within a channel. 

Streams may be established in any order (within a given channel, or globally). In addition, a (P)SIG needs not wait for 
the establishment of one stream to be complete, before commencing the establishment of another stream. Such 
considerations are out of the scope of the present document. 

The channel shall be in the Channel Open state (see subclause 8.3.1.6.3) for a (P)SIG to initiate a stream state machine. 
The channel state machine, as defined in subclause 8.3.1.6, continues to operate in Channel Open state during the 
operation of the stream state machine. Accordingly, both C(P)SIG and (P)SIG processes shall properly handle any and 
all channel-level messages valid in Channel Open state (these messages are not shown in the stream state machine). 

Closure of a channel (Channel Not Open state) causes the immediate closure of all streams open in the channel (reset of 
the stream state machine to Stream Not Open state). 

The stream state machine is found in figure 15. Each state found in this state machine is defined in subclauses 8.3.1.7.1 
to 8.3.1.7.7. 
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stream_trigger_enable_request 
C=^P 
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C <^P 
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Figure 15: C(P)SIG <=> (P)SIG stream state machine 
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8.3.1.7.1 Stream Not Open 

This state represents the initiahzation of the stream state machine. At this point, the stream has either not been 
initiaUzed, or has been closed. The channel in which the stream is found shall be in the Channel Open state in 
order to proceed. 

The (P)SIG initializes a stream by sending a stream_setup message to the C(P)SIG on the other end of the 
stream. stream_setup is the only permissible message in the Stream Not Open state. Parameters of 
stream_setup identify the transport stream (TS) associated with the stream, and list every service in the TS at 
the time the stream_setup is sent. Transmission and receipt of stream_setup move the state machine to the 
Stream Setting Up state. 

8.3.1.7.2 Stream Setting Up 

From this temporary and short-lived state, the C(P)SIG shall respond with either a stream_status or a 
stream_error message: 

The streain_status message acknowledges successful stream establishment, and that the stream is 
open. Transmission and receipt of stream_status move the state machine to the Stream Open state; 

The stream_error message acknowledges that the C(P)SIG could not open the stream, and that the 
stream shall be closed by the (P)SIG. One or more error codes explain the failure. Transmission and 
receipt of stream_error move the state machine to the Stream In Error state. 

8.3.1.7.3 Stream Open 

The stream is open and operational, and capable of performing all operations with exception of action 
triggering by the (P)SIG. Thirteen kinds of stream-level messages can be sent while in Stream Open state: 

- The C(P)SIG sends a stream_trigger_enable_request message to enable the receipt of (P)SIG action 
triggers in the stream. Parameters of stream_trigger_enable_request indicate, for any or all services in the 
TS, which kinds of triggers the C(P)SIG wants to receive, and how long in advance of the action the 
C(P)SIG wants to be triggered. Transmission and receipt of stream_trigger_enable_request move the state 
machine to the Stream Trigger Enabling state; 

The C(P)SIG sends a table_request message to request data from any PSI, SI or private table 
currently transmitted. This does not change the state of the stream state machine. The (P)SIG shall 
respond to each table_request message with a table_response message; 

The (P)SIG sends a table_response message to supply data from any PSI, SI or private table currently 
transmitted, as requested by the C(P)SIG in a table_request message. This does not change the state of the 
stream state machine. However, /or a given stream, the (P)SIG shall respond to table_request messages in 
the order received. Table_response may be sent only in response to table_request; 

The C(P)SIG sends a descriptor_insert_request message to request the insertion of CAS-specific 
private data in the TS. The private data is a list (possibly empty) of (a) private descriptors, and/or 
(b) private_data_bytes for a PAT or PMT CA_descriptor. Other parameters indicate the precise location 
within the TS in which to insert the data, and, optionally, with which triggered action the data insertion 
should be synchronized. The (P)SIG shall respond to each descriptor_insert_request message with a 
descriptor_insert_response message. The descriptor_insert_request message may be sent at any time from 
this state. This message does not change the state of the stream state machine; 

The (P)SIG sends a descriptor_insert_response message in response to the descriptor_insert_request 
message. Parameters indicate either successful data insertion in the TS or reasons for failure. The 
descriptor_insert_response message does not change the state of the stream state machine. However, /or a 
given stream, the (P)SIG shall respond to descriptor_insert_request messages in the order received. 
Descriptor_insert_response may be sent only in response to descriptor_insert_request; 
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- The C(P)SIG sends a PID_provision_request message to request from the (P)SIG the PID value the 
head-end has assigned to a particular stream; this stream is identified by a unique identifier. The (P)SIG 
shall respond to each PID_provision_request message with a PID_provision_response message. The 
PID_provision_request message may be sent at any time from this state. This message does not change the 
state of the stream state machine; 

- The (P)SIG sends a PID_provision_response message to provide the C(P)SIG with the PID value 
requested by the C(P)SIG in a PID_provision_request message. The PID_provision_response message 
does not change the state of the stream state machine. PID_provision_response may be sent only in 
response to PID_provision_request; 

The (P)SIG sends a stream_service_change message to signal the addition, deletion or move (TS 
and/or service reassignment) of a service. This message is not acknowledged by the C(P)SIG, and does 
not change the state of the stream state machine. Note that the head-end (any (P)SIG) shall send this 
message to all C(P)SIG processes operating in the Stream Open or Stream Trigger-Enabled state; 

If the (P)SIG wants to close the stream for any reason, it sends a stream_close message. Transmission 
and receipt of stream_close move the state machine directly to the Stream Not Open state. Stream_close 
may be sent at any time from this state. This message is not acknowledged by the C(P)SIG; 

If the C(P)SIG wants to close the stream for any reason, it sends a stream_close_request message. 
Transmission and receipt of stream_close_request move the state machine to the Stream Closing state. 
Stream_close_request may be sent at any time from this state; 

Either the C(P)SIG or the (P)SIG can send a stream_test message, in order to verify the error-free 
operation of the stream. This does not change the state of the stream state machine. Stream_test may be 
sent at any time from this state; 

If the stream is in an error-free situation, the receiver of the stream_test message shall reply with a 
stream_status message. This does not change the state of the stream state machine. Stream_status may be 
sent only in response to stream_test; 

If the stream has unrecoverable errors, the receiver of the stream_test message shall reply with a 
stream_error message. One or more error codes explain the failure. Transmission and receipt of 
stream_error move the state machine to the Stream In Error state. 

8.3.1.7.4 Stream Trigger Enabling 

This temporary and short-lived state is entered only after the C(P)SIG sends a stream_trigger_enable_request 
message while in the Stream Open state or in Stream Trigger Enabled state. One kind of stream-level 
messages can be sent while in Stream Trigger Enabling state: 

- The (P)SIG sends a stream_trigger_enable_response message in reply to the C(P)SIG. Parameters of 
stream_trigger_enable_response indicate, for any or all services in the TS, which kinds of triggers the 
C(P)SIG can actually receive, and approximately how long in advance of the action the C(P)SIG will 
actually be triggered. Transmission and receipt of stream_trigger_enable_response move the state 
machine to the Stream Trigger-Enabled state (whether or not any triggers are really enabled). 
Stream_trigger_enable_response may be sent only in response to stream_trigger_enable_request. 
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8.3.1.7.5 Stream Trigger-Enabled 



This state represents the normal steady-state operation of the stream state machine. The stream is open and 
operational, and capable of performing all operations, including (a) action triggering by the (P)SIG, and 
(b) requests for CAS-specific private data insertion by the C(P)SIG. 

Fourteen kinds of stream-level messages can be sent while in Stream Trigger-Enabled state. The first thirteen 
are the same as for the Stream Open state; see subclause 8.3.1.7.3. The additional type of stream-level 
messages is as follows: 

the (P)SIG sends a trigger message to signal an action of one of the following types: 

new DVB SI EIT Following event; 

new head-end information about a future DVB SI EIT event; 

creation, modification or closure of an ECM stream; 

modification of an ECM, EMM or private data FID; 

user-defined (per commercial agreement). 

Parameters indicate the trigger type, and all information required to precisely qualify the action that caused 
the trigger. 

The trigger message is not explicitly acknowledged by the C(P)SIG. However, the trigger shall be referenced 
by a subsequent descriptor_insert_request message (see below) if the C(P)SIG wants to synchronize private 
data transmission with the triggering action. 

The trigger message may be sent at any time from this state. This message does not change the state of the 
stream state machine. 

8.3.1.7.6 Stream In Error 

This temporary and short-lived state is used only to represent the fact that the C(P)SIG has encountered and 
reported an unrecoverable stream error: 

The (P)SIG sends a stream_close message to the C(P)SIG. Transmission and receipt of stream_close 
move the state machine to the Stream Not Open state. 

8.3.1.7.7 Stream Closing 

This temporary and short-lived state is used only to represent the fact that the C(P)SIG has requested closure 
of the stream: 

The (P)SIG sends a stream_close_response message to the C(P)SIG, to confirm closure of the stream. 
Transmission and receipt of stream_close_response move the state machine to the Stream Not Open state. 

8.3.1 .8 Summary of messages permissible in each state 

Table 33 provides a listing of the channel-level and stream-level messages that may be generated in each of 
the states of both state machines. 
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Table 33: Message/state cross-reference for the C(P)SIG <=> (P)SIG state machines 



Message 


State 


Channel (assumes Stream Not Open) 


Stream (assumes Channel Open) 


Not Open 


Setting Up 


In Error 


Open 


Not Open 


Setting Up 


In Error 


Closing 


Open 


Trigger 
Enabling 


Trigger 
Enabled 


channel setup 


X 






















channel status 




X 




X 


X 


X 


X 


X 


X 


X 


X 


channel test 








X 


X 


X 


X 


X 


X 


X 


X 


channel close 






X 


X 


X 


X 


X 


X 


X 


X 


X 


channel error 




X 




X 


X 


X 


X 


X 


X 


X 


X 


stream setup 










X 














stream status 












X 






X 




X 


stream test 


















X 




X 


stream close 














X 




X 




X 


stream close request 


















X 




X 


stream close response 
















X 








stream error 












X 






X 




X 


stream trigger enable request 


















X 




X 


stream trigger enable response 




















X 




stream service change 


















X 




X 


trigger 






















X 


table request 


















X 




X 


table response 


















X 




X 


descriptor insert request 


















X 




X 


descriptor insert response 


















X 




X 


PID provision request 


















X 




X 


PID provision response 


















X 




X 
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8.3.2 C(P)SIG ^ (P)SIG message syntax and semantics 

This section provides precise syntax and semantics for each of the messages in the C(P)SIG <^ (P)SIG 
connection-oriented protocol. 
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8.3.2.1 



List of message parameters for the C(P)SIG <->■ (P)SIG protocol 



Table 34: Parameter syntax in C(P)SIG <=> (P)SIG messaged-based protocol 



Parametertype 


Parameter 


Type (/ Units) 


Lengtti (bytes) 


OxOOOD 


access_criteria 


user defined 


variable 


0x0100 


bouquetjd 


uimsbf 


2 


0x0101 


CA_clescriptor_insertion_mode 


uimsbf 


1 


0x0102 


customCASJd 


uimsbf 


4 


0x0103 


custom_channel_id 


uimsbf 


2 


0x0104 


custom_stream_id 


uimsbf 


2 


0x0105 


descriptor 


Per MPEG/DVB; see 
ISO/IEC13818-1 [7] 

and 
ETSI EN 300 468 [1] 


variable 


0x0106 


descriptor_insert_status 


uimsbf 


1 


0x0107 


duration 


uimsbf 


3 


0x0108 


EClVI related data 
ESJd 

flow_super_CAS_id 
flow id 
flow_PID 
access_criteria 




variable 


0x0109 


DVB reserved 


- 


- 


0x01 OA 


DVB reserved 


- 


- 


0x01 OB 


ESJd 


uimsbf 


2 


0x01 OC 


event_id 


uimsbf 


2 


0x01 OD 


event_related_data 
eventjd 
duration 
startjime 
private_data 




variable 


0x01 OE 


flow id 


uimsbf 


2 


0x01 OF 


flow_PID 


uimsbf 


2 


0x0110 


flow_PID_change_related_data 
flowjype 

flow_super_CASJd 
flow id 
flow_PID 




9 


0x01 1 1 


flow_super_CASJd 


uimsbf 


4 


0x0112 


flowjype 


uimsbf 


1 


0x0113 


lnsertion_delay 


tcimsbf (/ ms) 


2 


0x0114 


insertion_delayJype 


uimsbf 


1 


0x0115 


last_sectionJndicator 


boolean 


1 


0x0116 


locationjd 


uimsbf 


1 


0x0117 


max_compJime 


uimsbf (/ sec) 


2 


0x0118 


maxstreams 


uimsbf 


2 


0x0119 


MPEG_section 


Per MPEG/DVB; see 
ISO/IEC13818-1 [7] 

and 
ETSI EN 300 468 [1] 


variable 


0x011 A 


networkjd 


uimsbf 


2 


0x01 IB 


original_networkJd 


uimsbf 


2 


0x01 1C 


private_data 


user-defined 


variable 


0x01 ID 


private data specifier 


uimsbf 


4 


0x01 IE 


(P)SIGjype 


uimsbf 


1 


0x01 1 F 


segment_number 


uimsbf 


1 


0x0120 


servicejd 


uimsbf 


2 


0x0121 


service_parameters 
servicejd 
triggerjist 
max_compJime 




8 


0x0122 


startjime 


bslbf 


5 


0x0123 


stream_changejimestamp 


bslbf 


5 


0x0124 


stream_changejype 


uimsbf 


1 


0x0125 


tablejd 


uimsbf 


1 


0x0126 


transactionjd 


uimsbf 


2 


0x0127 


transport_streamJd 


uimsbf 


2 


0x0128 


trigger id 


uimsbf 


2 
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Parametertype 


Parameter 


Type (/ Units) 


Length (bytes) 


0x0129 
0x01 2A 


triggerjist 
trigger type 


bslbf 
uimsbf 


4 
4 


0x012Bto0x6FFF 


DVB reserved 


- 


- 


0x7000 
0x7001 


error_status 
error information 


TBD 
user defined 


2 

variable 


0x7002 to 0x7FFF 
0x8000 to OxFFFF 


DVB reserved 
user defined 


- 


: 



8.3.2.2 



Parameter semantics 



This section gives the semantic of the parameters and fields used in this protocol. When depending on the message 
context, some parameters can be completed in each message description in further sections. 

access_criteria: this parameter carries the access criteria concerning an ECM stream; 

bouquet_id: this parameter is the value of the bouquet_id field as defined by ETSI EN 300 468 [1]; 

- CA_descriptor_insertion_mode: this parameter is provided by a CPSIG/CPSISIG and indicates whether a 
PSIG/PSISIG has to insert the skeleton of CA_descriptors; such a skeleton corresponds to the CA_descriptor as 
defined in table 2.51 of ISO/IEC 13818-1 [7] with an empty private_data_byte part; it can have the following values: 

0x01: the skeleton of the CA_descriptor is always inserted by the PSIG/PSISIG; 

- 0x02: no CA_descriptor skeleton is inserted by the PSIG/PSISIG; the CPSIG/CPSISIG is always responsible 
for the generation of this descriptor; 

- other values: DVB reserved. 

custom_CAS_id: this parameter is the unique identifier of a C(P)SIG sharing a channel with a (P)SIG; 

custoin_channel_id: this parameter is the identifier of a channel established by a (P)SIG with a C(P)SIG. It is 
unique per custom_CAS_id; 

custoin_stream_id: this parameter is the identifier of a stream established by a (P)SIG with a C(P)SIG for a 
transport stream. It is unique per channel; 

- descriptor: this field represents an instance of a descriptor provided by a C(P)SIG and to be inserted by the 
(P)SIG; 

descriptor_insert_status: this parameter indicates if a descriptor insertion requested by a C(P)SIG to a (P)SIG 
has been done correctly or has failed, according to the following values: 

0x00: insertion has been done correctly; this value is significant after the actual insertion; 

0x01: insertion failed because of the request was inconsistent (e.g. bad value for location_id, lack of some 
parameters for a given location_id); this value is significant immediately after the descriptor insertion request and 
prior the actual insertion; 

0x02: insertion has failed because the target table is not generated by the (P)SIG; this value is significant 
immediately after the descriptor insertion request and prior the actual insertion; 

0x03: insertion has failed because an error occurred at the moment of insertion of the descriptors in the table 
(e.g., missing space); this value is significant after the actual insertion attempt; 

- other values: DVB reserved. 

duration: this parameter contains the duration of the event in hours, minutes and seconds. The format is six 4-bit 
BCD digits. Example: 01:45:30 is coded as 0x014530; 

ECM_related_data: this field provides the C(P)SIG with the necessary information concerning an ECM stream 
that is going to be opened, closed or modified, whose PID is about to change, or that is attached to an event. It 
includes the following subfields: 
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- ES_id; 

flow_id: the identifier of the ECM stream; 

flow_super_CAS_id: the Super_CAS_id the ECM belongs to; 

flow_PID: the PID value of the concerned ECM stream; 

access_criteria. 

error_information: this parameter describes an error reason; its values are given in subclause 8.3.4.16; 

error_status: this parameter describes an error reason; its values are given in subclause 8.3.4.16; 

ES_id: this parameter is the identifier of an Elementary Stream to which the ECM stream is attached. It is equal 
to the rank of the description of the Elementary Stream in the PMT. The value identifies the whole service; 

event_id: this parameter is the value of the event_id field as defined by ETSI EN 300 468 [1]; 

event_related_data: this field describes a DVB-event. The trigger message does not contain this parameter 
when the value of trigger type is different from 'following event' and 'future event'. It comprises the following 
sub fields: 

event_id; 

duration; 

start_time; 

- private_data. 

flow_id: this parameter uniquely identifies a stream for a given stream type and a given flow_super_CAS_id; 

flow_PID: this parameter is the PID value of a stream. It is left-padded with zeroes to fill 2 bytes; 

flow_PID_change_related_data: this field provides the C(P)SIG with the necessary information concerning an 
ECM, EMM or private data stream whose PID is about to change. It includes the following subfields: 

flow_type; 

flow_super_CAS_id; 

flow_id; 

- flow_PID. 

flow_super_CAS_id: this parameter identifies the CA system and the CA subsystem a stream belongs to; 
flow_type: this parameter identifies the type of a stream: 

- 0x00: EMM; 
0x01: private data; 

- 0x02: ECM; 

- other values: DVB reserved. 

insertion_delay: this parameter gives the amount of time between the time of a trigger cause and the time at 
which the descriptors associated to this trigger cause should be inserted. If insertion_delay is negative, the descriptor 
insertion shall be done before the trigger cause; 

insertion_delay_type: this parameter indicates to the (P)SIG timing requirements for transmission of the updated 
table, with respect to the event start time or ECM modification (as determined by the trigger_type parameter). This 
parameter can have either of these values: 

0x01 = "immediate": the (P)SIG shall immediately insert the set of descriptors in the table; 
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0x02 = "synchronized": the (P)SIG shall synchronize the insertion of the set of descriptors with the cause 
identified by trigger_id. An insertion_delay parameter indicates the amount of time between this cause and the 
time of the insertion of the descriptors in the table; 

- other values: DVB reserved. 

last_section_indicator: this parameter is a boolean used in a set of messages carrying table sections to C(P)SIG; 
when true in a message, it indicates that this message is the last one in the sequence of responses; 

location_id: this parameter identifies the table and descriptor loop (if applicable) in which a (P)SIG is to insert a 
set of descriptors. See table 32 for values; 

max_comp_time: this parameter defines the delay for which a trigger precedes the corresponding scheduled 
action; depending on message context this delay is the one estimated by a (P)SIG or the one wanted by a C(P)SIG; 

max_streains: this parameter gives the maximum number of streams supported for a channel by a C(P)SIG or a 
(P)SIG, depending on message context; 

MPEG_sectioii: this parameter includes one and only one MPEG-2 PSI or DVB-SI section; 

network_id: this parameter is the value of the network_id field as defined by ETSI EN 300 468 [1]; 

original_network_id: this parameter is the value of the original_network_id field as defined by 
ETSI EN 300 468 [1]; 

private_data: this parameter corresponds to the event related private data. Its contents are private; 

private_data_specifier: this parameter contains the value of a private_data_specifier as defined by 
ETSI EN 300 468 [1] and ETSI ETR 162 [3]; 

(P)SIG_type: depending on the message context this parameter identifies a (P)SIG as a PSISIG, PSIG or SIG or 
a C(P)SIG as a CPSISIG, CPSIG or CSIG. See table 29 for values; 

segment_number: this field represents the number of the segment of an EIT schedule. Refer to 
ETSI ETR 211 [4] for the definition of a segment; 

service_id: this parameter is the value of the service_id field as defined by ETSI EN 300 468 [1] for a DVB 
service, or the PAT program_number of an MPEG-2 program; this parameter allows to refer to an MPEG2 program, 
which is not a DVB service; 

service_parameters: this field includes a set of the following subfields: 

service_id; 

trigger_list; 

max_comp_time. 

start_time: this parameter contains the start time of the event in Modified Julian Date (MJD) and Universal 
Time, Coordinated (UTC) formats. This 5-byte field is coded as 40 bits: the 16 LSBs of MJD, followed by six 4-bit 
Binary Coded Decimal (BCD) digits representing UTC. Example: 93/10/13 12:45:00 is coded as 0xC079124500; 

streain_change_timestamp: this field signals the scheduled date and time of a stream change. The format is the 
same as the one of start-time field; 

stream_change_type: this parameter signals the type of stream change being made: 

0x01: service creation; 

0x02: service deletion; 

- other values: DVB reserved. 

- tablejd: this parameter is the value of the table_id field as defined by ISO/IEC 13818-1 [7]; 
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transactionjd: this parameter is the unique identifier of a command; depending on message context, this 
parameter may allow to identify a corresponding response; 

transport_stream_id: this parameter is the value of the transport_stream_id as defined by ISO/IEC 13818-1 [7]; 

trigger_id: this parameter uniquely identifies a trigger occurrence. Such a trigger_id defined in a message may 
be referred to later on by another message; 

triggerjist: this parameter is a 32-bit vector, each bit of which corresponds to a trigger type, according to table 
30. A bit set to 1 means that the corresponding trigger type is concerned. Depending on message context this vector 

gives: 

either the intrinsic trigger possibilities of a (P)SIG (at channel setup); 

or the trigger types a C(P)SIG wants to receive (at trigger enable request); 

or the effective trigger types a (P)SIG can generate according to its intrinsic possibilities and to the C(P)SIG 
requests. 

- trigger Jype: this parameter identifies the type of trigger. See table 30 for values. 



8.3.3 Channel-level messages 



This section defines the syntax and semantics of each channel-level message. It refers to the syntax and semantic of 
parameters given in subclause 8.3.2; however for some parameters according to a particular message context, 
complementary descriptions can be given to complete or to replace descriptions given in subclause 8.3.2. 

8.3.3.1 ChanneLsetup message: C(P)SIG ^ (P)SIG 

The channel_setup message is sent by a (P)SIG from the Channel Not Open state, to establish a channel with a C(P)SIG. 



Parameter 


Number of instances in message 


transactionjd 
custom_CASJd 
custom channel id 
(P)SIGjype 
triggerjist 
max streams 





transactionjd is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

(P)SIG Jype identifies the (P)SIG as a PSIG, SIG or PSISIG. 

triggerjist gives the trigger types the (P)SIG can actually generate. 

max_streanis informs the C(P)SIG as to the maximum number of streams supported by the (P)SIG for this channel. 

8.3.3.2 ChanneLstatus message: C(P)SIG ^ (P)SIG 

The channel_status message is used either: 

- by a C(P)SIG from the Channel Setting Up state, to indicate successful channel setup; 

- by either a C(P)SIG or a (P)SIG from the Channel Open state, to indicate the status of a channel. This message 
follows a channel_test message issued by the process that shares the channel in question when no error has been 
detected. 
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Parameter 


Number of instances in message 


transactionjd 

custom channel id 

(P)SIG_type 

triggerjist 

max_streams 

CAdescriptorinsertionmode 


1 
1 
1 
1 
1 
Oto 1 



transactionjd: is set to the trans action_id of the message to which channel_status refers. This is the transaction_id of 
the previous channel_setup or a channel_test message. 

(P)SIG_type: identifies the type of the message sender as a PSISIG, PSIG or SIG if (P)SIG or as a CPSISIG, CPSIG or 
CSIGifC(P)SIG. 

triggerjist: lists the kinds of action triggers supported by the (P)SIG for this channel. When channel_status is issued by 
the C(P)SIG (as a result of a channel_setup or a channel_test issued by the (P)SIG), this parameter shall be ignored by 
the (P)SIG. 

max_streanis: is used in one of two ways: 

when channel_status is a response to channel_setup, the C(P)SIG imposes its max_streams limitation on the 
(P)SIG. This shall be less than or equal to the value of max_streams supplied by the (P)SIG during channel_setup; 

when channel_status is a response to channel_test, max_streams defines the maximum number of streams 
supported on this channel. This is the value of max_streams returned by the C(P)SIG after channel_setup. 

CA_descriptor Jnsertion_mode: this parameter is provided by the CPSIG/CPSISIG and indicates whether the 
PSIG/PSISIG has to insert the skeleton of the CA_descriptor; this skeleton corresponds to the CA_descriptor as defined 
in table 2.51 oflSO/IEC 13818-1 [7] with an empty private_data_byte part; this parameter is mandatory and significant 
only when channel_status is issued by the CPSIG as response to a channel_setup command, otherwise it shall be ignored 
or can be omitted; it can have the following values: 

0x01 : the skeleton of the CA_descriptor is always inserted by the PSIG; 

0x02: no CA_descriptor skeleton is inserted by the PSIG; the CPSIG is always responsible for the generation of 
this descriptor; 

other values: DVB reserved. 

8.3.3.3 Channeljest message: C(P)SIG ^ (P)SIG 

The channel_test message is sent by either a C(P)SIG or a (P)SIG from the channel Open state, to verify that: 

the TCP connection is still alive; 

the channel is in an error-free condition. 

The receiver of the channel_test message shall reply with a channel_status message if the channel is free of errors, or a 
channel_error message if errors occurred. 



Parameter 


Number of instances in message 


transactionjd 
custom channel id 


1 
1 



transactionjd: is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

8.3.3.4 ChanneLclose message: C(P)SIG ^ (P)SIG 

The channel_close message is sent by the (P)SIG to indicate that the channel is to be closed. This message is not 
acknowledged. 
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Parameter 


Number of instances in message 


transactionjd 
custom channel id 


1 
1 



transactionjd: is the unique identifier of an instance of this command. 

8.3.3.5 ChanneLerror message: C(P)SIG ^ (P)SIG 

The channel_error message is sent by the recipient of a channel_test message or by the C(P)SIG at any time to indicate 
that an unrecoverable channel error occurred. 



Parameter 


Number of instances in message 


transactionjd 
custom_channelJd 
error_status 
error information 


1 

1 
1 ton 
Oton 



If this message is generated by the C(P)SIG on unrecoverable error, transactionjd is the unique identifier of an 
instance of this command; if this message is a response to a previous channel_test message, transactionjd is set to the 
transactionjd of this channel_test message. 



8.3.4 Stream-level messages 



This section defines the syntax and semantics of each stream-level message. It refers to the syntax and semantic of 
parameters given in subclause 8.3.2; however for some parameters according to a particular message context, 
complementary descriptions can be given to complete descriptions given in that section. 



8.3.4.1 



stream_setup message: C(P)SIG ^ (P)SIG 



The stream_setup message is sent by a (P)SIG from the Stream Not Open state, to establish a new stream with a 
C(P)SIG. This message carries the values of service Jd of all the services broadcast in that transport stream. 



Parameter 


Number of instances in 




message 


transaction id 


1 


custom channel id 


1 


custom stream id 


1 


network id 


1 


original_networkJd 


1 


transport_streamJd 


1 


service id 


Oto n 



transactionjd: is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

The transport stream associated with this custom_streamJd is identified by networkjd, original_networkJd and 
transport_streamJd. 

Each service (DVB service or MPEG2 program, see servicejd parameter description in subclause 8.3.2.2) present in 
the TS shall be described by a servicejd parameter. The (P)SIG is required to signal NVOD reference services in this 
manner, even if it does not support private data insertion synchronized with NVOD reference events. The 
stream_service_change message is used to signal the addition or deletion of a service. 

8.3.4.2 Stream_status message: G(P)SIG ^ (P)SIG 

The stream_status message is used either: 

- by a C(P)SIG from the Stream Setting Up state, to indicate successful stream setup; 
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- by either a C(P)SIG or a (P)SIG from the Stream Open, Stream Trigger Enabling, or Stream Trigger-Enabled 
state, to indicate the status of a stream. This message follows a stream_test message issued by the process that shares 
the stream in question. 



Parameter 


Number of instances in message 


transactionjd 
custom_channel_id 
custom_stream_id 
service id 


1 

1 

1 

Oto n 



transactionjd: is set to the transaction_id of the message to which stream_status refers. This is the transaction_id of 
the previous stream_setup or a stream_test message. 

All service_id parameters concerning the TS shall be supplied, in a same way as for the stream_setup message, when 
stream_status is issued by a (P)SIG. When stream_status is issued by the C(P)SIG (as a result of a stream_setup or a 
stream_test issued by the (P)SIG), this parameter is not used. 



8.3.4.3 



Streamjest message: C(P)SIG ^ (P)SIG 



The stream_test message is sent by either a C(P)SIG or a (P)SIG from the Stream Open state, to verify that the stream is 
in an error-free condition. 

The receiver of the stream_test message shall reply with a stream_status message if the stream is free of errors, or a 
stream_error message if unrecoverable errors have occurred. 



Parameter 


Number of instances in message 


transactionjd 
custom_cliannelJd 
custom stream id 


1 
1 

1 



transactionjd: is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

8.3.4.4 Stream_close message: C(P)SIG ^ (P)SIG 

The stream_close message is sent by the (P)SIG to indicate that the stream is to be closed. This message is not 
acknowledged by the C(P)SIG. 



Parameter 


Number of instances in message 


transactionjd 
custom_cliannelJd 
custom stream id 


1 
1 

1 



transactionjd: is the unique identifier of an instance of this command. 

8.3.4.5 Stream_close_request message: G(P)SIG -^ (P)SIG 

The stream_close_request message is sent by the C(P)SIG to request the (P)SIG to close a stream. 



Parameter 


Number of instances in message 


transactionjd 
custom_cliannelJd 
custom stream id 


1 

1 
1 



transactionjd: is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

8.3.4.6 Stream_close_response message: G(P)SIG ^ (P)SIG 

The stream_close_response message is sent by the (P)SIG in response to a stream_close_request message. 
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Parameter 


Number of instances in message 


transactionjd 
custom_channel_id 
custom stream id 


1 
1 

1 



transactionjd: is set to the transactionjd of the message to which stream_close_response refers. This is the 
transactionjd of the previous stream_close_request message. 



8.3.4.7 



Stream_error message: C(P)SIG ^ (P)SIG 



The stream_error message is sent by the recipient of a stream_test message or by the C(P)SIG at any time to indicate 
that an unrecoverable stream error had occurred. 



Parameter 


Number of instances in message 


transactionjd 
custom_cliannelJd 
custom_streamJd 
errorstatus 
error information 


1 

1 

1 
1 ton 
Oton 



If this message is generated by the C(P)SIG on unrecoverable error, transactionjd is the unique identifier of an 
instance of this command; if this message is a response to a previous stream_test message, transactionjd is set to the 
transactionjd of this stream_test message. 



8.3.4.8 



Stream_service_change message: C(P)SIG <— (P)SIG 



The stream_service_change message is sent by the (P)SIG to signal a modification in service existence in a TS (addition 
of a service to a TS or deletion of a service from a TS). 

More sophisticated functions such as servicejd change or the move of a service from one TS to another TS can be 
achieved by combining these two basic addition and deletion functions. 

The head-end (any (P)SIG) shall send a stream_service_change message to all C(P)SIG processes operating in the 
Stream Open or Stream Trigger-Enabled state. 

This message should be issued by the (P)SIG no later than the scheduled service change. The advance notification time 
for this message is not defined by the present document. 

This message is not acknowledged by the C(P)SIG. 



Parameter 


Number of instances in message 


transactionjd 

custom_channelJd 

custom_streamJd 

servicejd 

stream_cliangejype 

stream cliange timestamp 


Oor1 



transactionjd: is the unique identifier of an instance of this message. 

8.3.4.9 Stream_trigger_enable_request message: G(P)SIG -^ (P)SIG 

The C(P)SIG sends this message to the (P)SIG for one of these reasons: 

Notify the (P)SIG that it is ready to receive action triggers, which ones it wants to receive, and (if possible) how 
long before the scheduled action it would like to receive the trigger. This happens after stream setup, when the 
stream state machine is in the stream_open state. Transmission of this message, and its receipt by the (P)SIG, move 
the stream state machine to the stream_trigger_enabling state. The (P)SIG is required to response with a 
stream_trigger_enable_response message, whose transmission and receipt move the stream state machine to the 
stream_trigger-enabled state. 
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Change the information suppHed to the (P)SIG in the most recent stream_trigger_enable_request message. This 
happens when the stream state machine is in the stream_trigger_enabled state. Transmission of this message and its 
receipt by the (P)SIG move the stream state machine to the stream_trigger_enabHng state. The (P)SIG is required to 
response with a stream_trigger_enable_response message, whose transmission and receipt move the stream state 
machine to the stream_trigger_enabled state back. 



Parameter 


Number of instances in message 


transactionjd 
custom_channel_id 
custom_stream_id 
service parameters 


1 

1 

1 

Oto n 



transactionjd: is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

The C(P)SIG may define for any service in the TS the trigger conditions it wants. For such each service, the C(P)SIG 
has to supply a service_parameters field including: 

a service_id parameter to identify the service; 

a triggerjist parameter to identify by which causes the C(P)SIG wants to be triggered; 

a max_comp_time parameter to define how far in advance of a scheduled action the C(P)SIG wants to receive 
the corresponding trigger. 

8.3.4.10 Stream_trigger_enable_response message: C(P)SIG <— (P)SIG 

The (P)SIG shall send this message in reply to a stream_trigger_enable_request message from the C(P)SIG. This 
message describes the types action triggers it can actually send to the C(P)SIG, on a per-service basis. 



Parameter 


Number of instances in message 


transactionjd 
custom_cliannelJd 
custom_streamJd 
service parameters 


1 

1 

1 

Oton 



transactionjd: is set to the transactionjd of the stream_trigger_enable_request message to which this message refers. 

For each service specified by the C(P)SIG in the preceding stream_trigger_enable_request message, the (P)SIG has to 
supply a service_parameters field including: 

a servicejd parameter to identify the service; 

a triggerjist parameter to identify for which causes the (P)SIG can generate triggers. This triggerjist is the 
logical AND of the following: 

the triggerjist from the preceding stream_trigger_enable_request message, which represents the triggers that 
the C(P)SIG would like to receive; 

a similar vector of the (P)SIG's capabilities for the current channel. This latter vector is supplied as the 
triggerjist in the channel_setup message; 

a logical vector where '0' bits represent the impossibility of generating certain trigger types for certain kinds 
of services. 

a max_comp Jime parameter to define how far in advance of a scheduled action the (P)SIG might possibly, 
given sufficient advance notification, send the corresponding trigger. The actual advance notification is estimated by 
the (P)SIG; the present document does not provide any mechanisms to guarantee the accuracy of this value. 
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8.3.4.1 1 Trigger message: C(P)SIG ^ (P)SIG 

The trigger message is sent by the (P)SIG to the C(P)SIGs under any of the circumstances, identified by the value for the 
trigger_type parameter: it is generated according to the trigger types allowed in the relevant 
stream_trigger_enable_response message. 

This message is not acknowledged. 

The content of the trigger message depends on the trigger_type value, as shown in the following table: 



Parameter 


Number of 


Number of 


Number of 


Number of 




instances in 


instances in 


instances in 


instances in 




message 


message 


message 


message 




Following event 


Future event 


ECM related event 
(all cases) 


PID change 


transaction id 










custom channel id 










custom stream id 










service id 








0/1 


triggerjd 










triggerjype 










event related data 












EClVI related data 


OtoN 





1 





flow PID change related data 











1 



When the trigger message pertains to following event, it shall contain as many ECM_related_data fields as there are 
ECM stream references (i.e. CA-descriptors) pertaining to the relevant CAS in the whole service description 
(i.e. in PMT). 

In a PID change trigger for an EMM stream, the service-id parameter shall be omitted; for other stream types, this 
parameter shall be included. 

transaction_id: is the unique identifier of an instance of this message. 

triggerjd: uniquely identifies this trigger occurrence: this trigger_id may be referred to later on by the 
descriptor_insert_request message. 

8.3.4.1 2 Table_request message: C(P)SIG -^ (P)SIG 

The table_request message is sent by the C(P)SIG to request MPEG-2 PSI or DVB SI table data from the (P)SIG. The 
value of the custom_stream_id parameter identifies the transport_stream on which the table is broadcast. 



Parameter 


Number of instances in message 


transaction id 


1 


custom channel id 


1 


custom stream id 


1 


table id 


1 


network id 


Oor1 


transport_stream_id 


Oor1 


original network id 


Oor1 


service id 


Oor1 


bouquetjd 


Oor1 


event id 


Oor1 


segment number 


Oor1 



transaction_id: is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

tablejd: is the value of the table_id field as defined by ISO/IEC 13818-1 [7]. It identifies the subtable requested by the 
CPSIG. 
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The C(P)SIG requests either complete PSI tables or SI sub-tables (see ETSI EN 300 468 [1]). As EIT Schedule 
sub-tables may be very large, the protocol optionally allows the C(P)SIG to request only the part of the EIT Schedule 
sub-table that concerns a specific event or a specific segment. In case the request concerns a specific event_id, the value 
of the table_id field shall be arbitrarily set to 0x50 for the events pertaining to the current TS, and 0x60 for the events 
pertaining to an EIT other. 

Table 3 1 indicates which parameters (network_id, original_network_id, transport_stream_id, service_id, 

bouquet_id, event_id, segmeiit_number) shall be present in the message, depending on the type of PSI/SI table data 
requested by the C(P)SIG. According to this table, the transport_stream_id and original_network_id parameters 
identifying the transport stream carrying the requested table are implicitly included in the custom_stream_id parameter. 

8.3.4.1 3 Table_response message: C(P)SIG ^ (P)SIG 

The table_response message is sent by the (P)SIG as a response to the table_request message. 

If the table does not fit into a single table_response message, the (P)SIG shall split the requested sub-table into several 
table_response messages with the same transaction_id. In every case the last table_response message for a table is 
indicated with the last_section_indicator set to "true". 

When this message is a response to a request for EIT data pertaining to a single event, the sections that are returned with 
this message are limited to the sections containing data pertaining to that event. Likewise, when this message is a 
response to a request for EIT data pertaining to a single segment, the sections that are returned with this message are 
limited to the sections containing data pertaining to that segment, i.e. 8 sections are returned. 

A single instance of a table_response may carry several MPEG_sections. 

If there is no MPEG_section, this means that the table that is requested is not generated by the (P)SIG. 



Parameter 


Number of instances in message 


transactionjd 
custom_channel_id 
custom_stream_id 
last_section_indicator 
MPEG section 


1 
1 
1 
1 
Oto n 



transactionjd: is set to the trans action_id of the table_request to which this message refers. 

8.3.4.1 4 DescriptorJnsert_request message: C(P)SIG -^ (P)SIG 

The descriptor_insert_request message is sent by the C(P)SIG. It indicates to the (P)SIG the descriptors that the 
C(P)SIG wants to be inserted in the PSI/SI tables. 

The descriptors in this message cancel and replace all the existing descriptors in the same location, uniquely associated 
to the same custom_CAS_id and for the same private_data_specifier if given in the message. In particular, using an 
empty list removes all descriptors of the custom_CAS_id in that location. 

This message carries all the information that the (P)SIG needs to know where and when to insert the descriptors. The 
table below describes the parameters that need to be present in the message, depending on the PSI/SI table which is 
addressed. 

Depending on the needs of the C(P)SIG, this message can be sent asynchronously or as a consequence of a previous 
trigger message. In the latter case, it contains the trigger_id parameter. 
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Parameter 


Number of instances in message 


transaction id 


1 


custom channel id 


1 


custom stream id 


1 


triggerjd 


Oor1 


insertion_delay_type 


1 


insertion delay 


Oor1 


location id 


1 


bouquetjd 


or 1 (see table 32) 


network id 


or 1 (see table 32) 


original_network_id 


or 1 (see table 32) 


transport_stream_id 


or 1 (see table 32) 


service id 


or 1 (see table 32) 


event id 


or 1 (see table 32) 


ES id 


or 1 (see table 32) 


private_data_specifier 


Oor1 


descriptor 


Oton 



transaction_id: is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

custom_stream_id: identifies the transport stream on which the table that has to be updated, is broadcast. 

triggerjd: refers to a previous trigger message. This field is optional. When not in the message the request for insertion 
is asynchronous. 

The value of insertion_delay_type can be "synchronized" only when the descriptor_insert_request message is related to 
a trigger message, via the trigger_id value. 

private_data_specifier: This parameter contains the value of a private_data_specifier (see ETSI EN 300 468 [1] and 
ETSI ETR 162 [3]); when this optional parameter is supplied, one of two cases applies: 

if the (P)SIG is able to generate a private_data_specifier_descriptor, the (P)SIG shall insert the following set of 
descriptors in the scope of a private_data_specifier_descriptor it generates with the value given by the 
private_data_specifier parameter; 

if the (P)SIG cannot generate a private_data_specifier_descriptor, the private_data_specifier parameter is 
ignored. 

Table 32 indicates, for each MPEG-2 PSI and DVB SI table, which parameters (locationjd, bouquetjd, networkjd, 
original_networkJd, transport_streamJd, servicejd, eventjd, ES Jd) are needed to define where the descriptor 
given in the descriptor parameter shall be inserted. According to this table, the transport_streamJd and 
original_networkJd parameters identifying the transport stream carrying the targetted table are implicitly included in the 
custom_streamJd parameter. 

8.3.4.15 Descriptor_insert_response message: C(P)SIG <*— (P)SIG 

The (P)SIG shall send this message in reply to a descriptor Jnsert_request message from the C(P)SIG. This message 
describes the status of the descriptor insertion. 

This message can be sent immediately after the reception of the corresponding request, or after the actual insertion has 
been attempted or completed. 



Parameter 


Number of instances in message 


transactionjd 
custom_channelJd 
custom_streamJd 
descriptor insert status 


1 

1 
1 
1 



transactionjd: is set to the transactionjd of the descriptor Jnsert_request message to which this message refers. 
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8.3.4.1 6 PID_provision_request message: C(P)SIG -^ (P)SIG 

The PID_provision_request message is sent by the C(P)SIG to receive from the (P)SIG the current PID value of a 
stream identified by the combination { flow_type, flow_super_C AS_id, flow_id } . 



Parameter 


Number of instances in message 


transactionjd 

custom_channelJd 

custom_streamJd 

flowjype 

flowsuperCASJd 

flow id 





transactionjd: is the unique identifier of an instance of this command, allowing to identify the corresponding response. 

8.3.4.1 7 PID_provision_response message: C(P)SIG ^ (P)SIG 

The (P)SIG shall send this message in reply to a PID_provision_request message from the C(P)SIG. This message gives 
the current PID value of a flow identified by the combination { flow_type, flow_super_C AS Jd, flowjd } . 



Parameter 


Number of instances in message 


transactionjd 

custom_channelJd 

custom_streamJd 

flowjype 

flow_super_CASJd 

flow id 

flow PID 





transactionjd: is set to the transactionjd of the PID_provision_request message to which this message refers. 

8.3.5 Error status and error information 

NOTE: TCP connection level errors are beyond the scope of the present document. Only channel, stream and 
application level errors are dealt with. These errors occur during the lifetime of a TCP connection. 
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Table 35: C(P)SIG connection-oriented protocol error values 



error status value 


Error type 


0x0000 


DVB Reserved 


0x0001 


invalid message 


0x0002 


unsupported protocol version 


0x0003 


uUnknown message_type value 


0x0004 


message too long 


0x0005 


unknown custom_stream_id value 


0x0006 


unknown custom_channel_id value 


0x0007 


too many channels on this C(P)SIG 


0x0008 


too many data streams on this channel 


0x0009 


too many data streams on this C(P)SIG 


OxOOOA 


unknown parameterjype 


OxOOOB 


unknown transaction id value in response message 


OxOOOC 


not compliant C{P)SIG- and (P)SIG-types 


OxOOOD 


invalid value for DVB parameter 


OxOOOE 


unknown custom_GAS_id value 


OxOOOF 


uUnknown bouquetjd value 


0x0010 


invalid CA_descriptor_insertion_mode value 


0x001 1 


invalid descriptor_insert_status 


0x0012 


inconsistent ESJd value 


0x0013 


unknown eventjd value 


0x0014 


uUnknown flowjd value 


0x0015 


uUnknown flow_super_GAS_id 


0x0016 


nvalid flow_type 


0x0017 


nvalid insertion_delay_type value 


0x0018 


nvalid locationjd value 


0x0019 


unknown networkjd value 


0x001 A 


unknown original network id value 


0x001 B 


invalid (P)SIG or C(P)SIG value 


0x001 C 


invalid stream_change_type value 


0x001 D 


invalid tablejd value 


0x001 E 


unknown transport_stream_id value 


0x001 F 


invalid trigger_type value 


0x0020 


unknown servicejd 


0x0021 


missing_service_id 


0x0022 


inconsistent length for DVB parameter 


0x0023 


missing mandatory DVB parameter 


0x0024 


invalid PID value 


0x0025 


unexpected trigger message 


0x0026 


unknown segment_number 


0x0027 


unknown triggerjd value 


0x0028 


unknown private_data_specifier value 


0x0029 


unknown descriptor_insert_status value 


0x002A 


custom_channel_id value already in use 


0x002B 


custom_stream_id value already in use 


0x002C 


flow id value already in use 


0x002D to 0x6FFF 


DVB Reserved 


0x7000 


unknown error 


0x7001 


unrecoverable error 


0x7002 to 0x7FFF 


DVB Reserved 


0x8000 to OxFFFF 


head-end specific / CA system specific / User defined 



8.4 S IMF-based protocol 



This section specifies the SIMF-based implementation of the C(P)SIG <^ (P)SIG interface. This implementation is 
based on the (P)SI Object Information Group of the Simulcrypt Identification Module (SIM) and the Operations 
Reference Point (ORP) operations paradigm that can be used between any components within Simulcrypt (see clause 7): 

this operations paradigm is introduced in subclause 8.4.1; 

its application to the C(P)SIG <^ (P)SIG interface and the conceptualization of the (P)SI object information 
group are introduced in subclause 8.4.2; 
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the (P)SI object information group is defined in subclause 8.4.2.4. 

8.4.1 Operations Reference Points (ORPs) 

The information exchange and synchronization between any number components is accomphshed through the SIMF as 
follows: 

the component advertises information such as SI/PSI information through a Management Information Base 
(examples SNMPv2 SMI MIB); that is done through a software agent (e.g. SNMPv2 agent) or through an object 
server (e.g. CORBA object server or RMI object server) or a web server; 

the component implements the SIMF events and logs modules which enables the asynchronous notification 
capability of the management system; 

the CAS Manager reads the Head-end/Uplink MIBs on a periodic basis, updates its custom information and 
registers itself as a recipient of events caused by updates in the Head-end/Uplink MIB; 

the CAS Manager updates the Head-end/Uplink with CA information on a periodic basis or upon receiving an 
event from the Head-end/Uplink or another CAS component through one of the following means; 

sets the Uplink MIBs through the network management protocol; 

updates its own MIBs, which causes events that result in notifications to be sent to the Head-end/Uplink 
manager. 

Figure 16 illustrates this synchronization and information exchange mechanism within the Uplink/Head-end. 

An Operation Reference Point (ORP) defines the interface between two Head-end/Uplink components. It replaces a 
custom communications protocol, which would need to be designed for that particular interface by a generic information 
exchange and event notification mechanism. 

The four basic ingredients, which enable ORP, based information exchange and synchronization are: 

information access through a standardized management protocol such as SNMP or CMIP or through a 
standardized OO protocol such as CORBA HOP or Java RMI; 

information advertisement through a management information base or an object broker; 

event trigger configuration, event forwarding configuration, and event notifications; 

- event logging. 
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Figure 16: Operations Reference Points 

8.4.2 Application of ORPs to the C(P)SIG ^ (P)SIG Interface 

Information exchange and synchronization between C(P)SI and (P)SI generators is accomplished as follows using 
ORPs: 

- the (P)SIG implements three SNMPv2 SMI modules: 

events module as specified in Common Information Modules Section; 

logs module as specified in Common Information Modules Section; 

(P)SI/C(P)SI information within the (P)SIG which is defined in a group consisting of 9 tables as follows: 

(P)SIG Information - this table is used to identify the different (P)SIG communications profiles; there is 
one entry in this table for each transport stream supported by the (P)SIG; if different (P)SIG configurations 
are supported for the same transport stream, there is one entry in this table for each of these configurations; 

(P)SIG Configuration - this table is used by the C(P)SIG to configure the (P)SIG with information 
defining triggering parameters for ECM, EMM, and Event triggers; 

ECM Trigger Table - this table contains all currently active ECM triggers; 

Flow PID Change Trigger Table - this table contains all currently active Flow PID change triggers; 

Event Trigger Table - this table contains all currently active event triggers; 

Descriptor Insert Table - this is the table used by the C(P)SIG to communicate descriptor insertion 
information to the (P)SIG; 

Descriptor Insert Descriptor Table - this is a sub-table of the Descriptor Insert Table containing the actual 
descriptors to be inserted; 

Table Provisioning Request Table - this is the table used by the C(P)SIG to request table provisioning by 
the (P)SIG; 
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PID Provisioning Table - this is the table used by the C(P)SIG to request Flow PID provisioning by the 
(P)SIG. 

The five transaction types across the C(P)SIG <^ (P)SIG ORP are: 

1) ECM/E vent/Flow Change Triggering - An event occurs within the (P)SIG which causes asynchronous 
information (e.g. (P)SI tables) to be communicated to the C(P)SIG and which may be followed up by the C(P)SIG 
inserting descriptors into the (P)SIG's (P)SI information; 

2) (P)SI Table Provisioning - The C(P)SIG requests and obtains (P)SI information from the (P)SIG; 

3) (P)SI Descriptor Insertion - The C(P)SIG requests that a descriptor be inserted into the (P)SIG's (P)SI tables; 

4) Transport Stream Service Changes - A transport stream service change is signalled by the (P)SIG by changing a 
variable in its static configuration table. All interested C(P)SIGs can receive value change notifications by 
configuring the (P)SIGs EFD table; 

5) PID Provisioning - The C(P)SIG requests and gets the current PID value of a particular stream identified by its 
unique identifier. 

8.4.2.1 ECM/Event/Flow Change Triggering 

The (P)SI/C(P)SI ORP facilitates ECM/Event/Flow Change Triggering as follows: 

1) the (P)SIG's Event Table is configured from start-up to generate events whenever there is a new entry in any of 
the three Trigger tables (i.e. the ECM, and Event Trigger tables); for each type of Trigger there is a different type of 
event; 

2) the (P)SIG advertises which types of triggers it supports through a SIM variable; 

3) the C(P)SIG configures the (P)SIG's Configuration Table with triggering parameters such as the types of triggers 
it wishes to receive, delay, etc; 

4) the C(P)SIG configures the (P)SIG's Event Forwarding Discriminator (EFD) table with event forwarding 
information such as IP address, notification type (confirmed/unconfirmed), filtering (i.e. CAS_id); 

5) the (P)SIG generates a trigger and populates the Trigger table as configured; 

6) the generation of a trigger causes an event to be generated, which is forwarded as defined in the EFD table; 

7) the C(P)SIG receives the event and reads the trigger from the (P)SIG. 

If the trigger causes the C(P)SIG to insert descriptors the C(P)SIG writes descriptors into the (P)SIG's descriptor insert 
table. 

8.4.2.2 (P)SI Table Provisioning 

The C(P)SIG requests (P)SI through the (P)SIG's Provisioning table. This table is just an interface to the (P)SI 
information within the (P)SIG or a proxy function to such information. The reply to the provisioning request contains 
the desired table or a part of the desired table if the table is too large to be sent in one reply. If the part number returned 
is the table part returned is the last or only table part. Otherwise, it is the sequence number of the next table part that 
should be retrieved by the C(P)SIG and the C(P)SIG has to continue requesting table parts until it receives one with the 
sequence number 0. 

8.4.2.3 (P)SI Descriptor Insertion 

The C(P)SIG requests (P)SI descriptor insertion through the (P)SIG's Descriptor Insert table. That table may also be just 
an interface to (P)SIG's descriptor insert application. The reply to the descriptor insert request informs the C(P)SIG 
whether the descriptor insertion was successful. 
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8.4.2.4 



Transport Stream Service Changes 



The (P)SIG announces changes in services on the transport stream by changing a variable in the (P)SIG Configuration 
Table that contains the service identifiers of all services on the transport stream. 

Each C(P)SIG configures the (P)SIG's event and EFD tables so that it will receive a notification if the (P)SIG transport 

stream service list variable changes. 



8.4.2.5 



PID Provisioning 



The C(P)SIG requests from the (P)SIG the PID value assigned by the head-end to a stream (ECM, EMM or private 
data) through the PID Provisioning table. That table may be also just an interface to (P)SIG's database. The stream is 
identified by its type, the identifier of the CA system and the CA sub-system the stream belongs to, and a unique stream 
number. The reply to this request contains the PID value. 

8.4.3 SIM (P)SIG Group Specification 

This group consists of nine tables: 

- (P)SIG Information Table; 

- (P)SIG Configuration Table; 

- ECM Trigger Table; 

- Event Trigger Table; 

Flow PID Change Trigger Table; 
Descriptor Insert Table, 
Descriptor Insert Descriptor Table; 
Table Request Table; 
PID Provisioning Table. 



8.4.3.1 



Information Table 



The first table is the (P)SIG information table. It is used by the (P)SIG to advertise its configuration, the transport 
streams it handles, and the services contained in all the transport streams. The table is indexed by simPsiglndex. The 
information consists of the following. 

Table 36: CIM - SIM (P)SIG Group - (P)SIG Information Table 



Object 


Size/Description 


Object Justification 


Head-end/ CAS 

IVIanager Maximum 

Access Rigfit 


simPsiglndex 


2 uimsbf/unique index of the 
(P)SIG Table 


identifies the (P)SIG 
communications profile 


read 


simPsigType 


1 uimsbf/{P)SIG type definition 


identifies whether the (P)SIG is a 
PSIG, aSIGoraPSISIG 


read 


simPsiglriggerSupport 


4 uimsbf/trigger type definition 


identifies which trigger types the 
(P)SIG supports 


read 


simPsigNetworl<ld 


2 uimsbf/the network identifier 
(see ETSI EN 300 468 [1]) 


identifies the network 


read 


simPsigONetworl<ld 


2 uimsbf/the original network 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the original network 


read 


simPsiglransStreamld 


2 uimsbf/transport stream 

identifier (see 

ETSI EN 300 468 [11) 


identifies the transport stream 


read 


simPsigTSServices 


bslbf/list of services identifiers 


identifies all services on the 
transport stream 


read 



£75/ 



113 



ETSI TS 103 197 VI. 1.1 (2000-06) 



8.4.3.2 



Configuration Table 



The second table is the configuration table. It is used to configure (P)SIG/C(P)SIG interaction. Each table row access is 
controlled by the administrative state variable and the row status variables as defined in the corresponding ITU-T and 
IETF standards. The table is indexed by the simPsigConfigCustCasId, the simPsigConfiglndex and the simPsiglndex. 
Each C(P)SIG enters one or more entries (rows) into this table. Each row defines one (P)SIG/C(P)SIG communications 
profile. 

Each communications profile is identified by the unique index. There may be multiple entries for the same Custom 
Conditional Access System Identifier (simPsigConfigCustCasId). Each entry defines the types of triggers that the 
C(P)SIG enables and the amount of time the C(P)SIG needs after receiving a trigger to insert descriptors into the 
(P)SIG's table (simPsigConfigMaxCompTime). The enabling is also characterized by any combination of the following 
parameters: service identifier and CA_descriptor insertion mode. 

Table 37 summarizes this information. 

Table 37: CIM - SIM (P)SIG Group - Configuration Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 

IVIanager Maximum 

Access Right 


SimPsigConfiglndex 


2 uimsbf/unique index of the 
(P)SIG Configuration Table 


identifies the C(P)SIG 
communications profile. 


read-create 


simPsiglndex 


2 uimsbf/unique index of the 
(P)SIG Table 


identifies the (P)SIG 
communications profile 


read-create 


simPsigConfigAdminState 


enumerated/administrative 

state of the table row (as in 

ITU-T 

Recommendation X.731 [8]) 


enables locking for 
synchronized access of 
multiple head-end or CAS 
network managers 


read-create 


simPsigConfigCpsigType 


1 uimsbf/C(P)SIG type 
definition 


identifies whether the C(P)SIG 
isaCPSIG, aCSIGor 
CPSISIG 


read-create 


SimPsigConfigCustCasId 


4 uimsbf/Custom CAS 
Identifier 


enables identification of 
C(P)SIGs 


read-create 


simPsigConfiglVlaxCompTime 


2 uimsbf/maximum time 
needed to process trigger by 
C(P)SIG 


enables (P)SIG to estimate the 
time between its triggering and 
descriptor insertion by the 
C(P)SIG 


read-create 


simPsigConfigServiceld 


2 uimsbf/service identifier (see 
ETSI EN 300 468 [11) 


identifies the service 


read-create 


simPsigConfigTriggerEnable 


2 uimsbf/trigger type definition 


identifies which trigger types 
the C(P)SIG wants 


read-create 


simPsigConfigCADInsMode 


enumerated/defines 
CA_descriptor insertion mode 


identifies whether the (P)SIG 
has to insert the skeleton of 
the CA descriptor 


read-create 


simPsigConfigEntryStatus 


enumerated/row creation 
status as defined in the 
RFC 1901 [15] to 
RFC 1908 [22] 


enables row creation control 


read-create 
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8.4.3.3 



ECM Trigger Table 



The third table is the ECM Trigger table. It is used for the (P)SIG to enter ECM Triggers and for the C(P)SIG to read 
them. Upon entering a new entry (ECM Trigger) into this table an event is automatically generated by the (P)SIG as 
specified in the Events Configuration Table of the Simulcrypt Events Module (SEM). This event is an object value 
change event and carries the instance identifier of ECM Trigger Table Index as changed object identifier and the 
Custom CAS identifier as specific problems. This allows EFD filtering in the SEM on the Custom CAS identifier and 
communicates the event type (through the event name) and the ECM Trigger index to the C(P)SIG through the EFD and 
through a value change notification. The value change notification can be either confirmed or unconfirmed. 

Each trigger is identified by the unique index (simPsigEcmTrlndex) and announces a single ECM stream creation or 
ECM stream deletion. The ECM stream created/deleted can be DVB Service wide or just component wide. If it is 
component wide a head-end wide Elementary Stream identifier is included in the table. 

There may be multiple table rows per trigger depending on whether there are multiple components attached or not. Each 
table row is uniquely indexed by the simPsigEcmTrlndex. 

Each table row consists of a network identifier (simPsigEcmTrNetworkId), the original network identifier 
(simPsigEcmTrONetworkId), the transport stream identifier (simPsigEcmTrTransStreamId), the service identifier 
(simPsigEcmTrServiceld), possibly the elementary stream identifier if the ECM stream is to be component level only 
(simPsigEcmTrEsId), the ECM trigger type which could be ECM stream open, close or access_criteria change 
(simPsigEcmTrType), the Super CAS Identifier (simPsigEcmTrSuCasId), the ECM unique identifier 
(simPsigEcmTrEcmId), the ECM PID (simPsigEcmTrEcmPid), the access criteria (simPsigEcmTrAccessCriteria). 

Table 38 summarizes this information. 

Table 38: CIM - SIM (P)SIG Group - ECM Trigger Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 

Manager IVIaximum 

Access Rig lit 


SimPsigEcmTrlndex 


2 uimsbf/unique identifier of 
the ECM Trigger 


identifies the (P)SIG ECM 
Trigger 


read-create 


SimPsigEcmTrNetworkId 


2 uimsbf/the network identifier 
(see ETSI EN 300 468 [1]) 


identifies the network 


read 


SimPsigEcmTrONetworkId 


2 uimsbf/the original network 

identifier 

(see ETSI EN 300 468 [1]) 


identifies the original network 


read 


Sim Psig EcmTrTransStream Id 


2 uimsbf/transport stream 

identifier 

(see ETSI EN 300 468 [1]) 


identifies the transport stream 


read 


SimPsigEcmTrServiceld 


2 uimsbf/the service identifier 
(see ETSI EN 300 468 [1]) 


identifies the service 


read 


SimPsigEcmTrEsId 


2 uimsbf/ the elementary 
stream identifier 


identifies the elementary 
stream if the ECMs are to be 
applied component wide only 
and not service wide 


read 


si m Psig EcmTrType 


enumerated/identifies the 
trigger type 


distinguishes between ECM 
stream open, close, and 
access criteria change triggers 


read 


SimPsigEcmTrSuCasId 


4 uimsbf/the Super CAS 
identifier 


identifies the CAS 


read 


SimPsigEcmTrEcmId 


2 uimsbf/the EClVI stream 
identifier 


identifies uniquely the ECM 
stream 


read 


SimPsigEcmTrEcmPid 


2 uimsbf/the ECM PID 


identifies the ECM PID 


read 


SimPsigEcmTrAccessCriteria 


bslbf/the access criteria 


specifies the access criteria 


read 
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8.4.3.4 



Flow PID Change Trigger Table 



The fourth table is the Flow PID Change Trigger table. It is used for the (P)SIG to enter Flow PID Change Triggers and 
for the C(P)SIG to read them. Upon entering a new entry (Flow PID ChangeTrigger) into this table an event is 
automatically generated by the (P)SIG as specified in the Events Configuration Table of the Simulcrypt Events Module 
(SEM). This event is an object value change event and carries the instance identifier of Flow PID Change Trigger Table 
Index as changed object identifier and the Custom CAS identifier as specific problems. This allows FED filtering in the 
SEM on the Custom CAS identifier and communicates the event type (through the event name) and the Flow PID 
Change Trigger index to the C(P)SIG through the EFD and through a value change notification. The value change 
notification can be either confirmed or unconfirmed. 

Each trigger is identified by the unique index (simPsigFlowTrlndex) and announces a single Flow PID change. Each 
table row consists of the trigger index (simPsigFlowTrlndex), the flow type (simPsigFlowTrType), the super CAS 
identifier (simPsigFlowTrSuCasId), the flow identifier (simPsigFlowTrFlowId), and the flow PID 
(simPsigFlowTrFlowPID). The table is indexed by the trigger index. 

Table 39 summarizes this information. 

Table 39: CIM - SIM (P)SIG Group - Flow PID Change Trigger Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA IManager 
lUlaximum Access Right 


SimPsigFlowTrlndex 


2 uimsbf/unique identifier of the 
Flow Trigger 


identifies the (P)SIG Flow 
Trigger 


read-create 


SimPsigFlowTrType 


enumerated/specifies the flow type 


the flow type can be ECM, 
EMM or private data 


read 


SimPsigFlowTrSuCasId 


4 uimsbf/the Super CAS identifier 


identifies the CAS 


read 


SimPsigFlowTrFlowId 


2 uimsbf/flow identifier 


uniquely identifies the flow 
for a given flow type and 
CAS identifier 


read 


SimPsigFlowTrFlowPID 


2 uimsbf/flow PID 


identifies the flow PID 


read 
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8.4.3.5 



Event Trigger Table 



The fifth table is the Event Trigger table. It is used for the (P)SIG to enter Event Triggers and for the C(P)SIG to read 
them. Upon entering a new entry (Event Trigger) into this table an event is automatically generated by the (P)SIG as 
specified in the Events Configuration Table of the Simulcrypt Events Module (SEM). This event is an object value 
change event and carries the instance identifier of the Event Trigger Table Index as changed object identifier and the 
Custom CAS identifier as specific problems. This allows EFD filtering in the SEM on the Custom CAS identifier and 
communicates the event type (through the event name) and the Event Trigger index to the C(P)SIG through the EFD and 
through a value change notification. The value change notification can be either confirmed or unconfirmed. 

The Event Trigger table is indexed by the unique Event Trigger Index (simPsigEvntTrlndex). 

Each trigger is identified by the unique index (simPsigEvntTrlndex). Each table row consists of a network identifier 
(simPsigEvntTrNetworkId), the original network identifier (simPsigEvntTrONetworkld), the transport stream identifier 
(simPsigEvntTrTransStreamId), the identifier of the service (simPsigEvntTrServiceld), the event identifier 
(simPsigEvntTrEventId), the start time (simPsigEvntTrStartTime), the duration of the event (simPsigEvntTrDuration), 
and the event related private data (simPsigEvntTrPrivateData). Table 40 summarizes this information. 

Table 40: CIM - SIM (P)SIG Group - Event Trigger Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 

Manager IVIaximum 

Access Right 


SimPsigEvntTrlndex 


2 uimsbf/unique index of the 
(P)SIG EVENT TriggerTable 


identifies the (P)SIG Event 
Trigger 


read 


simPsigEvntTrNetworl<ld 


2 uimsbf/the networl< identifier 
(see ETSI EN 300 468 [1]) 


identifies the network 


read 


simPsigEvntTrONetworl<ld 


2 uimsbf/tlie original network 

identifier 

(see ETSI EN 300 468 [1]) 


identifies the original network 


read 


SimPsigEvntTrTransStreamId 


2 uimsbf/transport stream 

identifier 

(see ETSI EN 300 468 [1]) 


identifies the transport stream 


read 


SimPsigEvntTrServiceld 


2 uimsbf/service identifier (see 
ETSI EN 300 468 [1]) 


identifies the service 


read 


SimPsigEvntTrEventId 


2 uimsbf/event identifier (see 
ETSI EN 300 468 [1]) 


identifies the event 


read 


Sim Psig EvntTrStartTi me 


5 bslbf/tlie start time in 
Modified Julian Date (IVIJD) 
and Universal Time, 
Coordinated (UTC) formats. 
The Field is coded as 16 bits 
of LSBs of IVIJD, followed by 
six 4-bit (BCD) digits 
representing UTC. 


Indicates the start time 


read 


SimPsigEvntTrDuration 


3 uimsbf/the event duration in 
hours, minutes, and seconds 
as six 4-bit BCD digits 


indicates the duration of the 
event 


read 


SimPsigEvntTrPrivateData 


bslbf/variable length event 
related user private data 


event related user private data 


read 



8.4.3.6 



Descriptor Insert Table 



The sixth table is the Descriptor Insert table. It is used for the C(P)SIG to enter (P)SI descriptors and for the (P)SIG to 
read them. Entering of a descriptor completes the cycle which was started by EMM/ECM/Event triggering. The actual 
descriptors to be inserted are written into the descriptor table. The descriptor insert status is communicated back in the 
descriptor insert reply message (i.e. each set is confirmed by a get-response in SNMP) or as a value change notification 
(i.e. the C(P)SIG configures events and EFDs to monitor the status object identifier instance of the descriptor table 
entry). Each table row access is controlled by the administrative state variable and the row status variables as defined in 
the corresponding ITU-T and IETF standards. 

Each descriptor is identified by the unique index (simPsigDescInsIndex). Each table row consists of the index and type 
of the trigger that caused the descriptor insertion (simPsigDescInsTrlndex, simPsigDescInsTrType), of a descriptor 
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insert location designator (simPsigDescInsLocationId), of a number of parameters specifying the descriptor, and also the 
descriptor insertion delay (simPsigDescInsDelay) and the descriptor insertion delay type (simPsigDescInsDelayType). 

Table 41 summarizes this information. 

Table 41 : CIM - SIM (P)SIG Group - Descriptor Insert Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 

Manager IVIaximum 

Access Right 


simPsigDesclnslndex 


2 uimsbf/unique index of the 
(P)SIG Descriptor Insert Table 


identifies the (P)SIG 
Descriptor Insert 


read-create 


simPsigDesclnsAdminState 


enumerated/administrative state 
of the table row (as in ITU-T 
Recommendation X.731 [8]) 


enables locking for 
synchronized access of 
multiple head-end or GAS 
network managers 


read-create 


simPsigDesclnsTrlndex 


2 uimsbf/unique index of the 
(P)SIG Trigger Table 


identifies the (P)SIG Trigger 
associated with this 
descriptor insertion 


read-create 


simPsigDesclnsTrType 


enumerated/identifies the type of 
the trigger 


indicates whether the trigger 
index is an ECM, or Event 
index 


read-create 


SimPsigDescInsLocationId 


enumerated/location identifier of 
the descriptor destination 


identifies the table and 
position where the descriptor 
is to be inserted 


read-create 


simPsigDesclnsNetworkId 


2 uimsbf/the network identifier 
(see ETSI EN 300 468 [1]) 


identifies the network 


read-create 


simPsigDesclnsONetworl<ld 


2 uimsbf/the original network 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the original network 


read-create 


simPsigDesclnsTransStreamId 


2 uimsbf/transport stream 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the transport 
stream 


read-create 


simPsigDesclnsServiceld 


2 uimsbf/service identifier (see 
ETSI EN 300 468 [1]) 


identifies the service 


read-create 


simPsigDesclnsElmStreamId 


2 uimsbf/elementary stream 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the elementary 
stream 


read-create 


simPsigDesclnsBouquetId 


2 uimsbf/bouquet identifier (see 
ETSI EN 300 468 [1]) 


identifies the bouquet 


read-create 


simPsigDesclnsEventId 


2 uimsbf/event identifier (see 
ETSI EN 300 468 [1]) 


identifies the event 


read-create 


simPsigDesclnsONetworkld2loop 


2 uimsbf/original network 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the original network 
in the 2"'^ loop 


read-create 


simPsigDesclnsNetworkldOther 


2 uimsbf/network identifier (see 
ETSI EN 300 468 [11) 


identifies the other network 


read-create 


simPsigDesclnsTransStreamld20rO 


2 uimsbf/transport stream 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the transport 
stream in 2"'^ loop or other 


read-create 


SimPsigDescInsDelayType 


enumerated/immediate or 
synchronized 


indicates whether the (P)SIG 
shall immediately insert the 
set of descriptors in the table 
or shall synchronize the 
insertion with a triggered 
event start or ECM stream 
modification 


read-create 



£75/ 



118 



ETSI TS 103 197 VI. 1.1 (2000-06) 



Object 


Size/Description 


Object Justification 


Head-end/ CA 

Manager IVIaximum 

Access Right 


simPsigDesclnsDelay 


tcimsbf/ms 


if the delay insertion type is 
synchronized this indicates 
the amount of time between 
the time the event is 
supposed to occur and the 
time at which the descriptors 
are to be inserted; a negative 
time indicates that the tables 
should be broadcast before 
the EClVI stream modification 
or event start 


read-create 


simPsigDescPrivDataSpfier 


2uimsbf (see 

ETSI EN 300 468 [1 land 

ETSI ETR162[3]) 


Private data specifier which 
is inserted into the TS by 
(P)SIG if possible. 


read-create 


simPsigDesclnsEntryStatus 


enumerated/row creation status 
as defined in the RFC 1901 [15] 
to RFC 1908 [221 


enables row creation control 


read-create 



8.4.3.7 



Descriptor Insert Descriptor Table 



The seventh table is an extension to the descriptor insert table. It consists of a list of descriptors 

(simPsigDescInsDescriptor) to be inserted and their insertion return status (simPsigDescInsDescriptorStatus). The table 
is indexed by the index of the descriptor insert table and by its own unique index. This allows multiple descriptors to be 
associated with the same insertion and thus also with the same trigger. Each table row access is controlled by the 
administrative state variable and the row status variables as defined in the corresponding ITU-T and IETF standards. 

Table 42 summarizes this information: 

Table 42: CIM - SIM (P)SIG Group - Descriptor Insert Descriptor Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 

IVIanager Maximum 

Access Right 


simPsigDesclnsDesclndex 


2 uimsbf/unique index of the 
(P)SIG Descriptor Insert 
Descriptor Table 


identifies the (P)SIG 
Descriptor Insert Descriptor 


read-create 


simPsigDesclnsDescAdminState 


enumerated/administrative 

state of the table row (as in 

ITU-T 

Recommendation X.731 [8]) 


enables locking for 
synchronized access of 
multiple head-end or CAS 
network managers 


read-create 


SimPsigDescInsDescriptor 


bslbf/the descriptor 


the descriptor to be inserted 


read-create 


SimPsigDescInsDescriptorStatus 


enumerated/the descriptor 
insertion status 


indicates whether the 
descriptor has been inserted 
or not 


read-create 


simPsigDesclnsDescEntryStatus 


enumerated/row creation 
status as defined in the RFC 
1901 [151 to RFC 1908 [221 


enables row creation control 


read-create 
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8.4.3.8 



Table Request Table 



The eighth table is the Table Request table. It is used for the C(P)SIG to request and retrieve (P)SI tables from the 
(P)SIG. The table is used as an interface to the (P)SI database. Since tables retrieved may exceed the maximum message 
size supported by the underlying transport (i.e. SNMP) a mechanism is provided to support arbitrary length tables. The 
reply to the provisioning request contains the desired table or a part of the desired table if the table is too large to be sent 
in one reply. If the part number returned is this table part returned is the last or only table part. Otherwise, it is the 
sequence number of the next table part that should be retrieved by the C(P)SIG and the C(P)SIG has to continue 
requesting table parts until it receives one with the sequence number 0. 

Each provisioning request is identified by the unique index (simPsigTblProvIndex). Each table row consists of a table 
identifier (simPsigTblProvTableld), of a network identifier (simPsigTblNetworkId), of a original network identifier 
(simPsigTblONetworkId), the transport stream identifier (simPsigTblTransStreamld), the service identifier 
(simPsigTblServiceld), the bouquet identifier (simPsigTblBouquetld), the event identifier (simPsigTblEventld), the 
segment number (simPsigTblSegmentNr), the table part requested (simPsigTblProvPart), and the table part number 
(simPsigTblProvPartNumber). The initial request always has a part number 0. Each subsequent request of the same table 
has the part number requested. 

Table 43 summarizes this information. 

Table 43: CIM - SIM (P)SIG Group - Table Request Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA Manager 
lUlaximum Access Right 


SimPsigTblProvIndex 


2 uimsbf/unique index of the 
(P)SIG Table Request Table 


identifies the (P)SIG Table 
Request 


read-create 


SimPsigTblProvTableld 


enumerated/table identifier 


identifies the table requested 


read-create 


SimPsigTblNetworkId 


2 uimsbf/the network 
identifier (see ETSI EN 
300 468 [1]) 


identifies the network 


read-create 


SimPsigTblONetworkId 


2 uimsbf/the original network 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the original network 


read-create 


SimPsigTblTransStreamld 


2 uimsbf/transport stream 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the transport stream 


read-create 


SimPsigTblServiceld 


2 uimsbf/service identifier 
(see ETSI EN 300 468 [1]) 


identifies the service 


read-create 


SimPsigTblBouquetld 


2 uimsbf/bouquet identifier 
(see ETSI EN 300 468 [1]) 


identifies the bouquet 


read-create 


SimPsigTblEventld 


2 uimsbf/event identifier 
(see ETSI EN 300 468 [1]) 


identifies the event 


read-create 


simPsigTblONetworkld2loop 


2 uimsbf/original network 

identifier (see 

ETSI EN 300 468 [11) 


identifies the original network 
in the 2"'' loop 


read-create 


simPsigTblNetworkldOther 


2 uimsbf/network identifier 
(see ETSI EN 300 468 [11) 


identifies the other network 


read-create 


simPsigTblTransStreamld20rO 


2 uimsbf/transport stream 

identifier (see 

ETSI EN 300 468 [1]) 


identifies the transport stream 
in 2"*^ loop or other 


read-create 


SimPsigTblSegmentNr 


2 uimsbf/segment 
number(see 
ETSI ETR 21 1 [41) 


number of the segment 


read-create 


SimPsigTblProvPart 


bslbf/the table part 


the table part 


read 


SimPsigTblProvPartNumber 


2 uimsbf/the table part 
number 


the table part number 


read-create 
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8.4.3.9 



PID Provisioning Table 



The ninth table is the PID Provisioning table. It is used for the C(P)SIG to request from the (P)SIG the PID value 
assigned by the head-end to a stream (ECM, EMM, or private data). The stream is identified by its type, the identifier of 
the CA system and the CA sub-system the stream belongs to, and a unique stream number. The reply to this request 
contains the PID value. 

The PID Provisioning table is indexed by the Super CAS identifier (simPsigProvSuCasId), and the flow identifier 
(simPsigProvFlowId). A PID provisioning request is made by the C(P)SIG by simply reading the corresponding PID 
variable in the table, i.e. an SNMP get on simPsigProvFlowPID indexed by the right flow type. Super CAS identifier, 
and flow identifier. The actual implementation of the table may be just an interface to an appropriate database or 
application. 

Table 44 summarizes this information. 

Table 44: CIM - SIM (P)SIG Group - PID Provisioning Table 



Object 


Size/Description 


Object Justification 


Head-end/ CA 

Manager Maximum 

Access Right 


simPsigPIDProvFlowType 


enumerated/flow type specification 


identifies whether the PID 
provisioning request is for an 
EClVI, EMIVI, or private data 
flow 


read-create 


simPsigPIDProvSuCasId 


4 uimsbf/Super CAS identifier 


identifies the CAS 


read 


simPsigPIDProvFlowld 


2 uimsbf/flow identifier 


uniquely identifies the flow 
for a given flow type and 
CAS identifier 


read 


simPsigPIDProvFlowPID 


2 uimsbf/flow PID 


identifies the flow PID 


read 



8.4.4 Conformance Requirements 

Table 45 summarizes the conformance requirements for management entities implementing the Simulcrypt Identification 
Module (SIM), by group. 

Table 45: CIM - SIM (P)SIG Group - Conformance Requirements 



Common Information 

Model - CIM Simulcrypt 

Identification Module 

Group 


Management 

Entity Hosting 

or Representing 

an ECMG 


Management 

Entity Hosting 

or Representing 

an EMMG 


Management 

Entity Hosting 

or Representing 

aPDG 


Management 

Entity Hosting 

or Representing 

a (P SIG 


Management 

Entity Hosting 

or Representing 

a C(P)SIG 




mndt 


optnl 


mndt 


optnl 


mndt 


optnl 


mndt 


optnl 


mndt 


optnl 


Ident Group 


X 




X 




X 




X 




X 




ECMG Group 


X 




















EIVIMG/PDG Group (without 
LAPG table) 






X 




X 












EMMG/PDG Group (LAPG 
Table) 








X 




X 










PSIG Group 














X 








CPSI Group 


















X 
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Timing and Playout Issues 



9.1 Timing issues 



In all systems there is a Crypto Period when data is scrambled with a particular Control Word. For STBs to regenerate 
the CW in time, the ECM playout has to be correctly synchronized with this CP. 

To accommodate different synchronization approaches, the SCS will be responsible for requesting enough CWs and 
ECM packets in advance of their playout time. The timing diagram in figure 17 illustrates this relationship between 
CW generation, ECM generation, ECM playout and Crypto Period. 

ECM Timing Diagram 



CWGen 



EClVl Gen A 



ECM Gen B 



EGIVI tx A 



ECM tx B 



Crypto 
Period 



CW (2) 



ECM (2) 



ECM (1) 



ECM 



CW(3) 



ECM (3) 



ECM (2) 



(1) 



ECM (2) 



ECM (1) 



CP (0) 



■> h<- 



CP(1) 



CW(4) 



ECM (4) 



ECM (3) 



ECM (3) 



CW(5) 



ECM (5) 



ECM (4) 



ECM (:4) 



EpM (2) 



ECM (3) 



CP (2) 



■>!-<- 



CP (3) 



CW(6) 



ECM (6) 



ECM (5) 



ECM (5) 



ECM (4) 



ECM (5) 



CP(4) 



CP(5) 



Figure 17: ECM timing diagram 

At the beginning of CP(2), at t8, the scrambler begins using CW(2) to encrypt the signal. Each CA system shall ensure 
that its STBs obtain this CW in advance of this point. 

CA system A achieves this by producing its ECM for a single CW only. As soon as ECM Gen. A receives CW(2), at tO, 
it is able to produce ECM(2), at tl . This ECM(2) is transmitted sufficiently prior to the beginning of CP(2), to ensure 
that the STB can obtain CW(2) before CP(2). 

CA system B achieves the same result by producing its ECM for two CWs. As soon as ECM Gen. B receives CW(2), at 
to, it is able to produce ECM(l), at tl. ECM(l), which encompasses CW(1) and CW(2), is transmitted from the middle 
of CP(1), at t4. This ensures that the STB can obtain CW(2) before CP(2) begins. After CP(2) begins, at t9, CW(2) and 
CW(3) are available in ECM(2). 
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9.2 Delay Start 



CW(2) 



CW(3) 



CWGen 



ECM Gen A 



ECM Gen B 



ECM tx A 



ECM tx B 



Crypto 
Period 




Figure 18: Delay_start and Delay_stop 

delay_start: This signed integer represents the amount of time between the start of a Crypto Period, and the start of the 
broadcasting of the ECM attached to this period. If it is positive, it means that the ECM shall be delayed with respect to 
the start of the Crypto Period. If negative, it means that the ECM shall be broadcast ahead of this time. This parameter is 
communicated by the ECMG to the SCS during the channel setup. 

delay_stop: This signed integer represents the amount of time between the end of a Crypto Period, and the end of the 
broadcasting of the ECM attached to this period. If it is positive, it means that the end of the ECM broadcast shall be 
delayed with respect to the end of the Crypto Period. If negative, it means that the ECM broadcast shall be ended ahead 
of time. This parameter is communicated by the ECMG to the SCS during the channel setup. 
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It is usual for delay_start and delay_stop to be equal, but this is not mandatory; this is illustrated in figure 19. The figure 
shows the case where ECM transmission is stopped around a CP boundary. 



CW(2) 



CWGen 



ECM Gen C 



ECM tx C 



Crypto 
Period 




Figure 19: End of ECM transmission around cryptoperiod boundary 

9.3 Playout Issues 

9.3.1 ECMs 

When an ECMG sends an ECM_datagram (in the ECM_response message) for a particular ECM stream it implicitly 
means that: 

the SCS shall trigger the playout of this ECM at the time calculated with the delay start parameter; 

the SCS shall stop the playout of the previous ECM of the same stream at the same time; 

in other words the playout of two ECMs of the same stream can never overlap; 

the playout of an ECM is also stopped by the SCS when the time calculated with the delay stop parameter is 
reached. 

If an ECMG fails (i.e. the SCS times-out while waiting for an ECM_response message), the SCS has the option to 
extend the duration of the current Crypto period (e.g. to attempt to reconnect or switch to a backup device). In such as 
case the playout of ECMs is extended accordingly. 

9.3.2 EMMs and Private Data 

The MUX should playout EMMs/Private Datagrams in the order in which they arrive. 
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9.4 Crypto Period Realignment 



If a new event starts in the middle of a Crypto Period (either from a program or a change in Access Criteria), Crypto 
Periods may need to be re-aligned. It is the SCS's responsibility to make sure that, during this re-alignment, no Crypto 
Period duration drops below the nominal_CP_duration. In other words, the Crypto Period can only be extended. For 
example, if 21:00:00 starts a new event and the nominal crypto period duration is 20 seconds, and a crypto period starts 
at 20:59:30, then the SCS is not allowed to make a 10 second crypto period between 20:59:50 and 21:00:00. Instead, if 
it needs to align Crypto periods with the start of the events, it shall lengthen the previous crypto period to 30 seconds, so 
that it ends exactly at 21:00:00. 



20:59:10 



20:59:30 



New Event 
21:00:00 

20:59:50 



21:00:20 



21:00:40 



Original 
Re-aligned 



■►i^ 



CP CP CP 

Figure 20: Event Realignment 
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Annex A (normative): 
System Layering 

A.1 Introduction 

Each paragraph in this annex describes a single system layer as defined within the OSI model. The presentation layer is 
not described in the context of the present document. 



A.2 Physical Layer 



The physical layer provides the physical facilities required to enable the linking together of hosts that need to exchange 
data. 

The physical layer interface shall be ethernet. 10 Base-T (or another fully compatible layer) shall be used on all the 
interfaces defined by the present document. 



A.3 Data Link Layer 



The data link layer provides the facilities that allow two hosts that are physically and directly connected (without a third 
host separating the two) to exchange data. The functionality of the data link layer is covered by the ethernet protocols. 



A. 4 Network Layer 



The network layer provides the facilities to allow two hosts to exchange data directly or indirectly in a network of 
intervening hosts and gateways. 

The network layer, providing point-to-point communication, shall be IP (Internet Protocol - RFC 791 [13]). Hosts within 
IP are uniquely identified by their IP address. 



A.5 Transport Layer 



The transport layer provides the facilities to allow two hosts, either directly or indirectly connected, to exchange data 
over one or several interconnected networks. Additionally, the transport layer allows communication to take place based 
on connections between an individually addressable end-point on one host and another individually addressable 
end-point on the same host or on another host. The transport layer allows as well communication in broadcast mode. 

The transport layer shall be TCP (RFC 793 [14]) or UDP (RFC 768 [12]), according to the application protocol. 



A.6 Session Layer 

The data exchange facility as provided by the session layer to the application layer has the following features: 

Connection Based or Broadcast (*): all communication takes place between two uniquely defined communication 
end-points, or from one to several communication end-points; 

Sequenced (*): All data transmitted arrives at its destination in the order it was sent; 

Reliable (*): Data integrity is maintained, no data is lost; 
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Two-way (*): Both communication end-points of a particular connection can send and receive data; 

Unformatted; The session layer does not impose any structuring on the data it transports; the data presents itself 
to the receiver as an unformatted data byte stream (data structuring into messages is a responsibility of entities in the 
application layer). 

The features (*) depend on the transport layer protocol (TCP or UDP) or on the session and presentation layers (specific 
or SNMP). 

The number of connections that can be concurrently open at any one time is determined by the operating system under 
which the applications making use of the stream layer facilities execute. Additionally, in the event of an unexpected 
connection closure or connection loss and in the event of data read or write errors, the entity in the application layer that 
opened the connection or performs the read or write operation is notified. 

The session layer, providing these facilities, shall be a socket stream interface. 



A.7 System Layering Overview/ Communications 
Protocol stack 



:! 



Application Layer 
Application 1 Application 2 





Stream 






Channel 
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\ Channel , 
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(OS! Session layer) Sockets 
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Transport Layer 



IP(Network Layer) 



Ethernet (Physical / Data Link Layer) 



Figure A.1 : Systems Layering overview diagram 

On the left of this diagram, the mappings between the entities ports, sockets, connections and sessions is depicted: 

'1 <-> r indicates a direct association between an instance of an entity of a given type and an instance of a lower 
layer entity; 

'1 <-> N' indicates that potentially multiple instances of an entity of a given type map onto a single instance of a 
lower layer entity. 
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A. 8 TCP or UDP Connection Establishment 

Connections between client and server are initiated by the client. After establishment of a connection, both client and 
server have an open socket, identifying the connection, allowing them to exchange data. IP address information required 
by the client to open a connection is made available by the server in one of two ways: 

Statically: IP address information is defined by static methods; 

Dynamically. This method may use a DNS (Domain Name Server). The DNS can be consulted by the client to 
retrieve the required information; 

TCP port or UDP port information required by the client to open a connection is made available by the server. 
Port number information is defined by static methods. 
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Annex B (informative): 
SCS Coexistence 

B.1 Introduction 

This annex describes how the ECMG <^ SCS message interfaces could be used to communicate with another SCS 
(e.g. in a hot-standby configuration). In a Simulcrypt environment all the information that an SCS needs to communicate 
with a Mux, is encompassed by the Channel Status, Stream Status, CW Provision and ECM Response messages. This 
information can be passed to another SCS, which can then use this information to maintain its internal status. 



B.2 Example scenario 



The EIS will trigger the beginning of a CA event by sending access conditions and start and stop times to SCSi. SCSi 
will then determine which ECMGs are involved with this CA event. It will establish connections, channels and streams 
with the appropriate ECMGs. During this establishment, each ECMG will pass, via the Channel and Stream Status 
messages, all ECMG specific data. SCS i will then begin passing CWs to the ECMGs, receiving ECM datagrams in 
response and synchronize the ECM playout. 

In the example given in figure B.l, SCSi will additionally pass all messages received by each ECMG and the 
information contained in the CW Provision message on to SCS2. This information can be transmitted to SCS2 using the 
same interface as the SCS <^ ECMG. The main difference is that the CW Provision message, which is normally sent by 
SCS] to the ECMG, will now be received by SCS2 from SCSi. 

This information will enable SCS2 to reproduce the environment (connections, channels and streams) running on SCSi. 
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ECMG 
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Figure B.1 : Example of SCS redundancy 
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Annex C (informative): 

Control word generation and testing 

C.1 Introduction 

The control word generator is an integral part of the DVB Simulcrypt system, which generates low-level cryptographic 
keys that are used directly to scramble content. It should supply control words that meet certain statistical properties for 
randomness. Using appropriate (preferably physical) generating techniques and applying statistical tests will reduce to 
an acceptable level the probability of inadvertently generating control words with deterministic properties. 

Since generating highly random control words and applying the appropriate tests for randomness imposes little 
incremental technical complexity or cost, there is great motivation for implementing the methods described below or 
their equivalent. Moreover, commercially available hardware and software solutions for this problem make it an easy 
task to generate control words with high confidence in their randomness qualities. 



C.2 Background 



The generated control words should approach as nearly as practicable true random sequences. In general, the criteria for 
producing cryptographically secure random sequences include: 

they have to appear random, that is they have to seem to an observer to possess the qualities of true random 
sequences; 

an observer should not be able to predict the next bit in a sequence even if armed with complete knowledge of the 
generating algorithm/hardware; 

a given sequence should not be reproducible by running a generator more than once using the same input; 

Certifying sequences by applying the statistical tests described below can satisfy criteria 1 and 2, and seeded pseudo 
random sequences can meet these requirements. However any pseudo random algorithm is just as subject to attack as is 
an encryption algorithm. 

Satisfying Criteria 1-3 produces sequences that approach true randomness (by most definitions) and are probably 
random enough for use as cryptographic keys in most applications, but (3) cannot be achieved using pseudo random 
techniques. This is not to imply that no pseudo random technique is acceptable for use in generating Simulcrypt control 
words, only that great care has to be taken to avoid generating sequences that that appear random but that can be 
successfully analysed by an attacker. This is not an easy task, but there are simple tests that can be applied to the 
algorithm during development that will help insure it satisfies criteria 1 and 2. For instance, an acceptable sequence 
should not be appreciably compressible (by more than about 1 or 2%) using commercial compression programs. 
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C.3 Generation 



The best method to generate random sequences involves using physical phenomena to produce a Gaussian distributed 
white noise source with a flat magnitude spectrum (± 1 db, 100 Hz - 120 kHz). Physical methods typically use a thermal 
or radioactive noise source and are fed to a high-speed comparator to produce a digital output. Such sources are readily 
available and are simple to construct, and their output cannot be replicated even though an attacker may possess an exact 
copy of the generator hardware (i.e. They satisfy goal 3 above). This cannot be said of pseudo-random sequences 
generated by LFSRs even when operated in combinatorial arrangements. Various attacks can be successfully mounted 
against such methods. 

Recommendation: 



Simulcrypt control word generators should preferably use a physical source such as thermal noise, diode noise, MISC or 
the equivalent to generate random sequences. Pseudorandom techniques should be used advisedly and only after 
exhaustive testing to insure at least criteria 1 and 2 are met. 



C.4 Control word randomness verification testing 

There are numerous tests for randomness that can be applied to sequences, however in practical implementations there 
are two fundamental tests that can be relied upon to detect any significant defect in both pseudo- and true random 
sequences. 

C.4.1 1/0 bias 

The 1/0 bias test is usually performed on a sequence of convenient length and the comparator is trimmed to produce a 
logical probability, p(0), of 0,5. 

P(0) = 0,5h- e± 0,001 

where e = bias factor 
XORing bits together will exponentially converge to: 

p(0) = 0,5 
A two-bit example: 

p(0) = (0,5 + ef + (0,5 - ef = 0,5 + 2e^ 
A four-bit example: 

p(0) = 0,5 + 8/ 
Recommendation: 
1/0 bias detection tests should be run on the generated sequences, and corrections should be made when needed. 

C.4. 2 Autocorrelation 

Autocorrelation is defined as a discernible relationship in the variation of a variable over time. In order for a random 
sequence to be non-deterministic, its autocorrelation property has to be minimized. There are many algorithms available 
to measure autocorrelation properties, and most specify the test to be run on small (100 kbit/s) blocks where actual 
values should not vary more than three standard deviations from expected values for two consecutive blocks. Depending 
on the required speed, the tests may be run continuously or at frequent intervals. 

Recommendation: 



Autocorrelation tests should be run on sequences at intervals sufficient to ensure with reasonable certainty that no 
deterministic properties exist. 
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C.5 Testing locations 



Although it is recommended that the above tests be conducted at the output of the control word generator, CA operators 
should consider conducting similar tests at the input of the of their ECMGs to confirm the randomness of the control 
words they receive. 
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Annex D (informative): 

Security IVIethod for the SCS ^ ECIVIG Interface 

The following is a recommended method for encrypting the clear control word data traversing non-secure networks 
between the SCS and ECMG devices. For simplicity, it is performed at the application level within the Simulcrypt 
protocol. Since the CW data consists of an 8-byte block transferred over the interface once per CP, it is quite 
straightforward to encrypt using a standard block encryption algorithm. Key management as specified here is both 
simple and effective, requiring minimal resources. This method is facilitated by using the CW_encryption parameter and 
its sub-parameters as specified in the CW_provision message format. 



D.1 Algorithm Selection 



Although the Algorithm_type parameter in the CW_encryption parameter allows the selection of multiple encryption 
algorithms, it is recommended that the head-end/uplink operator and the external CA provider(s) agree beforehand on 
the algorithm to be used. The Algorithm_type parameter is also useful in specifying the key entropy (i.e. 40 bit vs. 
56 bit) used with a particular algorithm where external CA systems are capable of both versions. Weakened key 
strengths are sometimes necessary to satisfy the requirements of governmental authorities. In the 40 bit case, 
two padding bytes of value 0x00 shall replace bytes 5 and 6 of the selected key as shown below. 

If the selected key value is: 9B F2 74 AO B 1 9 A E6 

Then the 40 bit adjusted key is: 00 00 74 AO B 1 9A E6 

It is the responsibility of the Simulcrypting participants to select an algorithm that is strong enough, appropriate to this 
application, and compliant with national restrictions. Examples of algorithms that may be suitable can be found in 
FIPS 46-1 [23]. 

The encryption mode specified is Electronic Code Book and can be used with any 56 bit block cipher. Encryption and 
decryption are shown in Figure D.l and D.2 respectively. 

56 bit key 



Clear 64 bit CW 



-> 



56 Bit Block Cipher 
Encrypt 



-^ Encrypted 64 bit CW 



Figure D.l : Control Word encryption (SCS head-end/uplinic function) 

56 bit key 



Encrypted 64 bit CW 



-> 



56 Bit Block Cipher 
Decrypt 



-^ Clear 64 bit CW 



Figure D.2: Control Word decryption (External ECMG function) 



D.2 Control Word processing 



Only the 8-byte control word data field in the CP_CW_combination parameter is subject to encryption. The control 
word data is parsed from the 2-byte CP data field prior to encryption and is re -concatenated with it following encryption. 
This maintains an 8-byte plaintext field and requires only a single iteration of the encryption algorithm. Moreover, 
additional processing steps such as padding are avoided. Figure D.3 illustrates the parsing operation. 
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CP 



cw 



2 Bytes 



8 Bytes 

Clear Field > — Encrypted Field 



Figure D.3: CP_CW_combination field parsing 

SCS devices need only implement the encryption mode of the algorithm, while ECMG devices need only implement the 
decryption mode. 



D.3 Key Management 



Under the present document, key management involves the generation, selection, and distribution of key data to be used 
in the algorithm for CW encryption. This has to be done in a standardized way in order to insure interoperability 
between SCS and ECMG devices. 



D.3.1 Key Generation/Distribution 



The encryption algorithm implementation in the present document uses key data generated by a good random source 
(see annex C) and stored on media for use in both SCS and ECMG devices. Each SCS (head-end/uplink) operator is 
responsible for securely generating the key data for his SCS <^ ECMG interface(s) and for securely distributing it upon 
request to all external CA operators for use in their ECMGs. In the event a key list is suspected or known to be 
compromised, the SCS operator is responsible for generating and distributing a replacement list as soon as possible. 
Moreover, SCS operators may agree to generate and distribute new key lists on a periodic basis to insure key security. 
The suggested size of the keyspace is 2 048 bytes. This provides 292 possible 7-byte keys per key list for use in the 
algorithm. 

Highly-cautious SCS operators may wish to detect and exclude weak and semi-weak keys when generating keylists, 
however due to the nature of the application, the occasional use of these keys does not pose a security threat. Moreover, 
if the random source is robust, neither weak nor semi-weak keys are likely to be generated with any significant 
probabihty. 

To facilitate seamless transition from one key list to another, two independent 2 048-bit lists are used. Both the active 
list and the future list shall reside on both the SCS and all Simulcrypting ECMGs before the head-end/uplink facility 
performs the transition function. The list in current use shall be identified using the most significant bit in the 
CW_encryption parameter; this bit is designated as Key_list_sel (key list select bit). When reset (0), the A key list is in 
use; when set (1), the B list is in use. Transition from one key list to the other is accomplished by setting or resetting the 
Key_list_sel bit. 

In order to avoid placing headers in the key lists, the SCS and ECMG software shall examine the Key_list_sel bit at the 
time lists are loaded to determine whether the list being loaded is to be designated the A or B list. If the active list is A, 
the list is loaded as B; if the active list is B, it is loaded as A. If no lists are active (during initialization) the software shall 
allow the operator to manually enter the designator. 

D.3.2 Selection 

Selection of the 56-bit key data for use in the algorithm is accomplished by using a randomly-generated 1 1-bit key select 
vector. This vector is used as an index into the 2 048 key space as shown in Figure D.4. 

Only every seventh address is legal as a key select vector (i.e. 0, 7, 14, 21, etc.) through 2 037. This provides 
292 possible completely independent keys. 
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2K memory map 



CW_key_ptr 



Byte 2047 



Byte 13 



Byte? 



Byte 1 



ByteO 



LS Byte 



Selected CW encryption key 



MS Byte 



Figure D.4: Example of Control Word encryption key selection 

The CW_encryption parameter is represented as a two-byte field as shown below. Bits 0-10 comprise the 
CW_key_pointer, and bits 11-13 are used to designate the cryptographic algorithm or key size in use. Bit 14 is used to 
invoke fixed key mode, and bit 15 is the A/B key list designator (Key_list_sel). 

Bit 14: Fixed_key_mode 
Bit 15: Keyjist_sel 







r 




LS Bit (0) 


1 










Algorithm_type 


CW_key_ptr 




Bits 11-13 


Bits 0-10 



Figure D.5: CW_encryption Parameter (two bytes) 

New keys are selected for each instance of the CW_provision message, and where more than one CW is conveyed in a 
single CW_provision message, all CWs are encrypted using the same key. One key is required per each CW encryption 
or decryption operation. 

In the event 40 bit keys are in use, the padding method previously described is applied to the selected key data. 



D.3.3 Key Pointer Distribution 



The present document uses a symmetric algorithm, which is the same key is used for both encryption and decryption. 
Therefore both the SCS and ECMG shall use the same key as selected by the CW_key_ptr parameter within the 
CW_encryption parameter. This parameter is generated in the SCS and shall be conveyed in the CW_provision message 
immediately following the CP_CW_combination parameter. Subclause 5.5.7 specifies the required CW_encryption 
parameter. The entire table is reproduced below for convenience; it includes the sub-parameters specific to this security 
method. 
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Parameter 


Number of instances in message 


ECM channel id 


1 


ECM stream id 


1 


CP number 


1 


CW_encryption 

CW_l<ey_ptr 
Algorithmjype 
Fixed_l<ey_mode 
Key list sel 


Otol 


CP CW combination 


CW per msg. 


CP duration 


Oto 1 


access criteria 


Oto 1 



CW_encryption: This parameter contains the four sub-parameters listed below that enable encrypting of control words 
over the SCS <^ ECMG interface. If the parameter is included in the CW_provision message, control word scrambling 
is invoked; if omitted, CWs are being issued in the clear. 

CW_key_ptr: This 1 1-bit field contains an index that points to the active CW encryption key contained on a 2 048 byte 
(or smaller) key list. It is a randomized value (1 of 292) generated within the SCS which points to the MS byte of a 
seven-byte key used in block cipher Electronic Code Book mode. Legal values include every 7th address in the 

2 048 space (0, 7, 14, 21, etc). 

algorithin_type: This field may be used either to signal the type of encryption algorithm in use for CW encryption or 
the key length of a given algorithm. It is useful where it may be desirable to change either the fundamental algorithm or 
its key length providing both the head-end and all external ECMGs have the appropriate capabilities. In most cases, the 
Simulcrypting participants will agree on these parameters in advance. 

fixed_key_mode: This bit is used to bypass the key list and use a key contained in ROM for encryption of the control 
word. This key will need to be agreed upon by all Simulcrypting participants. The security method described in Annex n 
uses a defined fixed key value. 

key_list_sel: In order to facilitate smooth changeover from one keylist to another, two independent lists should be 
maintained on each ECMG and the SCS. This bit allows selection of one of the two lists as the active list. 



D.3.4 Fixed Key Mode 



There are instances in practical cryptosystems when it is desirable to temporarily encrypt messages under a common 
fixed key. This mode is useful when troubleshooting system failures, during initialization, or when the SCS has not 
installed a key list. It provides a fallback mode that is more secure than sending control words in the clear. When 
invoked, the SCS encrypts all CWs under the same fixed key, which is located in ROM and is not part of any key list. 
Fixed key mode is invoked using the Fixed_key_mode bit (14) of the CW_encryption parameter (see figure D.5). When 
set (1), the encryption key is selected from the appropriate (A or B) key list as designated by the pointer value and the 
key list select bit. When reset (0), the fixed key is used as the encryption key. The ECMG cannot invoke fixed key 
mode. The value of the fixed key is: 

- 56-bit version: 4D Al 9F FO AF 6B 8F; 

- 40-bit version: 00 00 9F FO AF 6B 8F. 

It was generated in accordance with annex C. Since this mode can be invoked at any time by the SCS, the ECMG 
software should include an alarm to alert operators when fixed key mode is in effect. 
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D.4 Encryption Function Toggling 

Although it is unUkely that either head-end operators or external CA providers will wish to discontinue CW encryption 
once it is invoked, there may be an occasional need to temporarily revert to clear CW transmission for system 
troubleshooting or for other reasons. This is accomplished by the SCS deleting the CW_encryption parameter from the 
CW_provision message. If the ECMG does not receive the CW_encryption parameter in the CW_provision message, it 
does not apply decryption to the received control words. Clear control should only be sent by prior arrangement between 
head-end operators and external CA providers or in emergencies; the ECMG does not have the capability to invoke clear 
CW transmission. ECMG designers may wish to include an alarm in their firmware that would activate upon detection 
of clear control word mode. 
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Annex E (informative): 

Summary of Requirements for C(P)SIG ^ (P)SIG interface 

This section provides a high-level summary of the requirements imposed on the head-end system and each CAS in 
support of the C(P)SIG ^ (P)SIG interface. 

The head-end and each CAS comply with the requirements presented in annex E, clauses E. 1 and E.2, respectively, as 
well as all specifications in documented in the above -described sections. 

E.1 Head-end system requirements 

The head-end shall be solely responsible for: 

1) Generating and broadcasting one or more transport streams (TSs) that conform to MPEG-2 and DVB 
specifications (EN 300 468 [1] through ETSI ETR 289 [5] and ISO/IEC 13818-1 [7]). 

2) Ensuring the MPEG-2 and DVB syntactic and semantic integrity of these TSs. 

3) Ensuring that each TS include all standard MPEG-2 PSI and DVB SI tables that are required by MPEG-2 and 
DVB specifications (specifically, ETSI ETR 154 [2] and ETSI ETR 21 1 [4]). There is no requirement on the 
head-end to generate any standard tables that are optional (e.g. EIT Schedule). 

4) Ensuring that each PSI and SI table (required or optional) include all descriptors required by MPEG-2 and 
DVB specifications, respectively (specifically, ETSI ETR 154 [2] and ETSI ETR 21 1 [4]), and optionally 
generating any other standard tables and/or descriptors defined by MPEG-2 and/or DVB. See also the next 
requirement. 

5) Including, as required per DVB and CAS-specific conditional access (CA) requirements, CA_descriptors in all 
PSI CAT and PMT tables. However, the head-end shall not include any private_data_bytes in CA_descriptors 
whose CA_system_id belongs to any CAS that is interfaced with the head-end (refer to ISO/IEC 13818-1 [7]). 

6) Optionally generating any private tables (i.e. with user-defined table_id) with MPEG-2 section syntax. (This is 
outside the scope of this interface. Commercial agreement should be used to avoid conflict with CAS-generated 
private tables transmitted on the PDG <^ MUX Interface). 

7) Optionally generating, for its own purposes, an ordered list of private descriptors (i.e. with user-defined tag 
value) for insertion in any PSI/SI table; and broadcasting this list of descriptors. Either of two methods may be 
used to prevent conflict with private descriptors generated by any CAS (clause E.2): 

logically separating the head-end's private descriptors with a private_data_specifier descriptor, whose 
private_data_specifier value is used only by the head-end (per commercial agreement). The present document 
strongly recommends this approach; or 

accordingly, the head-end may employ commercial agreement or some other unspecified means to prevent 
conflicts in private descriptor tag usage and interpretation. 

8) Scheduling DVB SI services and events. While this is not specific to the C(P)SIG <^ (P)SIG Interface, the 
head-end shall inform the CAS(s) of new and/or changed services and events, per the "triggering" requirement 
presented below. 

9) Configuration and initialization of the head-end (P)SIG processes defined in subclause 8.2.1 of the present 
document. Specifically, either a single PSISIG, or a {PSIGh-SIG} pair, shall be configured. 

10) Hosting one or more CAS and their C(P)SIG processes, as defined in subclause 8.2. 1, and supporting each 
CAS per the requirements presented. 

11) Maintaining mutual separation and independence of each CAS. 
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12) Triggering (signalling) each CAS before, or upon, the occurrence of any or all of the following actions: 

new DVB SI EIT Following event; 

new head-end information about a future DVB SI EIT event; 

creation, modification or closure of an ECM stream; 

- user-defmed (per commercial agreement); 

in order to enable triggering, the CAS shall first tell the head-end which types of triggers it wants to receive, 
on a per-service basis. In addition, the CAS shall specify how far in advance of the action it wants to receive the 
trigger (if possible); 

in this context, "service" means either a DVB-defmed service or an MPEG-2 program, either being defined 
by a PAT program_number entry and a PMT section. 

13) Fulfilling CAS requests for the insertion of a list of private descriptors in standard PSl and SI tables. The head- 
end shall therefore include any private descriptor requested by any CAS, provided that (a) the descriptor is 
syntactically valid, and (b) the integrity of the PSl/Sl table(s) can be maintained. The descriptor list insertion 
may be synchronized with a triggered action (see above), or asynchronous, as requested by the C(P)S1G (see 
below). 

14) Preventing conflict, among CASs and with the head-end, in the usage and interpretation of private descriptors. 
Either of two methods may be used: 

logically separating each respective CAS's list with a private_data_specifier descriptor, whose 
private_data_specifier value is used only by the CAS (per commercial agreement). The present document 
strongly recommends this approach; or 

employing commercial agreement, or some other unspecified means, to prevent conflicts in private descriptor 
tag usage and interpretation. 

15) Fulfilling CAS requests to receive data from any PSl or SI currently transmitted. If the head-end generates EIT 
Schedule tables, they shall always be returned to the CAS in the clear, even if scrambled for broadcast (see 
ETSI EN 300 468 [1], subclause 5.1.5). 

16) Reporting specified error conditions per the above-defined interactions with the CASs. 

17) Ensuring and maintaining all communications, networking, database access and so forth within the head-end, so 
as to ensure that all other requirements are met. Such intra-head-end interfaces are implementation-dependent, 
and outside the scope of the present document. 



E.2 CAS's C(P)SIG requirements 

Each CAS shall be solely responsible for: 

1) Informing the head-end as to the types of event- and ECM-related triggers it wants to receive, on a per-service 
basis. In this context, "service" means either a DVB-defined service or an MPEG-2 program defined by a PAT 
program_number entry and a PMT section; 

2) Processing action triggers received from the head-end; 

3) Optionally generating, for its own purposes, an ordered list of private descriptors for insertion in any standard 
PSI/SI table(s) generated by the head-end: 

each list supplied is associated with a CAS-specific private_data_specifier (per commercial agreement). It is 
the responsibility of the head-end to decide whether to separate descriptor lists via private_data_specifier 
descriptors, or by some other unspecified means. The present document strongly recommends the use of 
private_data_specifier descriptors; 

the CAS may request that the descriptor list insertion be either synchrorrized with a triggered action, or 
asynchronous. 
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4) Sending the descriptor list to the head-end for broadcast: 

a CAS cannot actually send or modify any PSI/SI table by itself. It can only request that the head-end insert 
its private descriptors in given tables. 

5) Maintaining each descriptor list and each set of the CA_descriptor private_data_bytes up-to-date, per CAS 
requirements. The CAS shall ensure that private descriptors are compatible with the PSI/SI tables in which they are 
transmitted, at the time they are transmitted; 

6) Reporting specified error conditions per the above -defined interactions with the head-end; 

7) Ensuring and maintaining all communications, networking, database access and so forth within the CAS, so as to 
ensure that all other requirements are met. Such intra-CAS interfaces are implementation-dependent, and outside the 
scope of the present document; 

8) Requesting for any PSI/SI table. 
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Annex F (informative): 

Example of C(P)SIG ^ (P)SIG Connection-oriented 

Solution Configuration 

The sample configuration presented here is referred to in subclause 8.3. 

Figure F.l shows this reference configuration at the component and channel level. Figure F.2 depicts all connections at 
the stream level. 



CAS1 



CPSIG 1A 



CSIG1B 



Ch 1 



HEAD-END SYSTEM 



Ch2 



Ch3 



CAS 2 



CPSISIG 2 



Ch4 



Ch5 




TS2 


services 


10,13,15 



PSIG 2A 


>S 




TS3 

services 
26 


SIG2B 


w 





Figure F.l : Example: Cliannels (Chi - Ch5) in a liead-end system witli two CASs 



F.1 Head-end processes and configuration data 

The head-end in this example includes two (P)SIGs. (P)SIG 1, a PSISIG, serves one transport stream, TSl. (P)SIG 2 
consists of two processes, a PSIG and a SIG; they serve two transport streams, TS2 and TS3. 

Tables F.l and F.2 show the information that the head-end might possibly require to define the (P)SIG head-end 
processes (recall that the present document does not define the format of this data): 

table F. 1 defines TS-related parameter; 

table F.2 defines (P)SIG-related parameters. 

For simplicity, this data has been organized into relational tables in near-canonical form (some cells may contain lists of 
values). The following conventions are used in this and all other configuration tables presented in this annex: 

Columns headed by names appearing in UNDERLINED ITALICS indicate key fields. A specific system implementation 
might provide a different set of key fields for any table. 

Cells marked with an asterisk (*) indicate data whose values are not of specific interest in understanding this example. 
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In addition, since the actual representation of this data is beyond the scope of the present document, the following are 
not to be inferred from this example; 

the completeness of this data: other data might be required; 

the location of this data (e.g. head-end and/or CAS); this would be determined by technical and/or commercial 
requirements. 

Whether this data is static or dynamic; some of each would generally be required. 

Table F.1 : TS configuration data (example, not normative) 



TRANSPORT 
STREAM 


TRANSPORT ST 

REAM 

Id 


ORIGINAL 

NETWORK 

id 


NETWORK 
ID 


SERVICE 
IDs 


TS1 


* 


* 


* 


1,2 


TS2 


* 


* 


* 


10, 13, 15 


TS3 


* 


* 


* 


26 



Table F.2: (P)SIG configuration data (example, not normative) 



(P)SIG NAME 


IP ADDRESS 


TCP PORT NO. 


(P)SIG TYPE 


TRANSPORT ST 
REAMS 


PSISIG 1 


* 


* 


3 


TS1 


PSIG 2A 


* 


* 


1 


TS2, TS3 


SIG2B 


* 


* 


2 


TS2, TS3 



F.2 CAS processes and configuration data 

Two CASs are hosted by the head-end. It is assumed that the head-end knows the CA_system_id (CASID) and 
private_data_specifier(s) used by each CAS. 

The C(P)SIG of CAS 1 consists of two processes, a CPSIG and a CSIG. The C(P)SIG of CAS 2 is a CPSISIG. 

Table F.3 shows the information that the head-end might possibly require to define the C(P)SIG CAS processes (recall 
that the present document does not define the format of this data). 

Table F.3: C(P)SIG configuration data (example, not normative) 



C(P)SIG 
NAME 


CUSTOM CAS Id 


IP ADDRESS 


TCP PORT 
NO. 


C(P)SIG 
TYPE 


CASID 


extension 


CPSIG 1A 


CASID-1 


1 


* 


* 


4 


CSIG IB 


CASID-1 


2 


* 


* 


8 


CPSISIG 2 


CASID-2 


1 


* 


* 


OxC 





F.3 Channels and configuration data 

Five channels are present in the system: 

channels Chi and Ch2 allow CAS 1 to request data from, and insert private data into, TS 1 . Chi supplies 
MPEG-2 PSI private data for insertion, and Ch2 similarly supplies DVB SI private data; 

NOTE: CPSIG 1 A may request DVB SI data via Chi, and CSIG IB may request MPEG-2 PSI data via Ch2. The 
kind of table data returned by the head-end via the table_response message is not restricted by the type of 
C(P)SIG that issued table_request. This principle holds, clearly, to all the other channels defined. 
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similarly, channel Ch3 allows CAS 1 to exchange data with TS2 and TS3. Only DVB SI private data is supplied 
for insertion; 

channels Ch4 and Ch5 allow CAS 2 to request data from, and insert private data into, TS2 and TS3. Ch4 supplies 
MPEG-2 PSI private data, and Ch5 similarly handles DVB SI private data. 

Table F.4 shows the information that the head-end might possibly require to establish all the channel connections (recall 
that the present document does not define the format of this data). 

Note the interpretation of the triggerjist values used: 

• 0x0000003F ('...00111111') says that the channel supports triggering on six kinds of actions; EIT future events, 
EIT following events, new ECM streams, ECM stream closure, ECM FID modification, and modification of 
ECM access criteria; 

• 0x0000003D ('...00111101') says that the channel supports triggering on all kinds of actions listed above, with 
exception of EIT future events. 

Table F.4: Channel configuration data (example, not normative) 



CHANNEL NAME 


CUSTOM 
CHANNEL ID 


C(P)SIG NAME 


(P)SIG NAME 


TRIGGER_ LIST 


MAX_ STREAMS 


Ch1 


1 


CPSIG1A 


PSISIG 1 


OxSF 


* 


Ch2 


2 


CSIG 1B 


PSISIG 1 


0x3F 


* 


Ch3 


3 


CSIG 1B 


SIG2B 


OxSF 


* 


Ch4 


4 


GPSISIG2 


PSIG 2A 


0x3D 


* 


Ch5 


5 


GPSISIG2 


SIG2B 


OxSF 


* 
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F.4 Streams and configuration data 

Eight streams are defined in this sample configuration; they are depicted in Figure F.2. 

Table F.5 shows the information that the head-end might possibly require to establish all the stream connections (recall 
that the present document does not define the format of this data). 



CAS1 



CPSIG1A 



CSIG1B 



CAS2 



CPSISIG2 



Ch1 



Ch2 



Ch3 



Ch4 



Ch5 



Stream S1 



Stream S2 



Stream S3 



Stream S4 



Stream S5 



Stream S6 



Stream S7 



Stream S8 



HEAD-END 




TS1 



TS2 




Figure F.2: Example: Stream interconnections for tlie exampie in figure F.I 
Table F.5: Stream configuration data (example, not normative) 



STREAM 
NAME 


CUSTOM 
STREAM id 


CUSTOM 
CHANNEL ID 


TRANSPORT 
STREAM 


SERVICEJds 


SERVICE 
PARAMETERS 


S1 


1 


1 


TS1 


1,2 


* 


S2 


1 


2 


TS1 


1,2 


* 


S3 


2 


3 


TS2 


10, 13, 15 


* 


S4 


3 


3 


TS3 


26 


* 


S5 


2 


4 


TS2 


10, 13, 15 


* 


S6 


3 


4 


TS3 


26 


* 


S7 


2 


5 


TS2 


10, 13, 15 


* 


S8 


3 


5 


TS3 


26 


* 
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Annex G (normative): 
ASN.1 MIBs description 

G.1 SIMMIB 

SIM-MIB DEFINITIONS: := BEGIN 

IMPORTS 

MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter32, IpAddress, 

BITS FROM SNMPv2-SMI 

TEXTUAL-CONVENTION, RowStatus, 

DisplayString FROM SNMPv2-TC 

MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-C0NF; 

simMIB MODULE-IDENTITY 

LAST-UPDATED "9707021700Z " 

ORGANIZATION "DVB Simulcrypt Technical Group " 

CONTACT-INFO " " 

DESCRIPTION 

" The MIB module for defining DVB Simulcrypt Conditional 
Access System configuration information. " 
: := {1 3 6 1 4 1 2696 1 1} 

AdministrativeState: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Administrative state as defined by ITU-T Recommendation X.734 [10] . " 
SYNTAX BITS 

{ 
locked(O) , 
unlocked (1 ) , 
shuttingDown (2) 
} 

ECMGSuCasId: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"The Super_CAS__id is represented as a 4 bytes unisgned integer. " 
SYNTAX Unsigned32 

FlowSuCasId: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"The Super__CAS„id is represented as a 4 bytes unisgned integer. " 
SYNTAX Unsigned32 

ECMGStreamId: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" The ECM_stream_id is represented as a 2 bytes unsigned integer. " 
SYNTAX INTEGER (0.. 65535) 

FlowId::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" The flow identifier is represented as a 2 bytes unsigned integer. " 
SYNTAX INTEGER (0.. 65535) 

ECMGChannelld: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" The ECM_channel_id is represented as a 2 bytes unsigned integer. '' 
SYNTAX INTEGER (0.. 65535) 

EMMGCommCapability : := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Type of communications capability between EMMG/PDG and Multiplexer: 
TCP or UDP or both. " 
SYNTAX BITS 

{ 
both(O) , 

tcpd) , 
udp (2) 
} 
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EMMGCommType : := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Type of communications capability between EMMG/PDG and Multiplexer: 
TCP or UDP . " 
SYNTAX BITS 

{ 
tcp{0) , 
udp { 1 ) 
} 

EMMGDataType: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Type of data carried in the EMMG/PDG Multiplexer stream. " 
SYNTAX BITS 

{ 

emm ( ) , 
other (1) 
} 

EMMGClientId: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Client_id: The client_id is a 32-bit identifier. It shall 
identify uniquely an EMMG/PDG across all the EMMGs/PDGs 
connected to a given MUX. To facilitate uniqueness of this 
value, the following rules apply: 

* In the case of EMMs or other CA related data, the two first 
bytes of the client_id should be equal to the two bytes of 
the corresponding CA__system„id. 

* In other cases a value allocated by DVB for this purpose 
should be used. " 

SYNTAX Unsigned32 

EMMGStreamId: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"Indicates the Data Stream Id. " 
SYNTAX INTEGER (0.. 65535) 

EMMGChannelld: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"Indicates the Data Channel Id. " 
SYNTAX INTEGER (0.. 65535) 

TriggerType: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" The type of a trigger in a PSI generator. " 
SYNTAX BITS 

{ 

dvbEvent (0) , 
f utureDvbEvent (1 ) , 
newEcmStream (2 ) , 
flowPidChange (3) , 
accessCriteriaChange (4) , 
ecmStreamClosure (5) 



ECMTriggerType: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" The type of an ECM trigger in a PSI generator. 
SYNTAX BITS 

{ 

ecmStreamOpen (0) , 
ecmStreamClose (1) , 
ecmStreamChange (2) , 
accessCriteriaChange (3) 
} 



DescriptorStatus: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" The return status of descriptor insertion. " 
SYNTAX BITS 

{ 

success (0) , 

unknownTrigger (1 ) , 
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unknownLocation (2) , 
unsupportedDelay (3) , 
unknownContext (4) , 
unknownOtherTS (5) , 
unknownNetwork (6) , 
unknownTS (7) , 
unknownES (8) , 
unknownBouquet (9) , 
unknownEvent (10) , 
tableNotSupported(ll) , 
tableFull (12) , 
other (13) 



InsertLocation: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Descriptor insertion location. 
SYNTAX BITS 



{ 

pmtLoopl (0) , 

pmtLoop2 (1 ) , 

cat (2) , 

nitLopplActualNet (3) , 

nitLoop2ActualNet (4) , 

nitLopplOtherNet (5) , 

nitLoop20therNet (6) , 

batLoopl (7) , 

batLoop2 (8) , 

sdtActualTS (9) , 

sdtOtherTS (10) , 

eitPFActualTS (11) , 

eitPFOtherTS (12) , 

eitScheduleActualTS (13) , 

eitScheduleOtherTS (14) 



ProvTableld ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Provision table identifier. " 
SYNTAX BITS 

{ 

pat (0) , 
cat(l) 
pmt (2) , 

nitActualNet (3) , 
nitOtherNet (4) , 
bat (5) , 

SdtActualTS (6) , 
SdtOtherTS (7) , 
eitPFActualTS (8) , 
eitPFOtherTS (9) , 
eitScheduleActualTS (10) , 
eitScheduleOtherTS (11) 



} 



DelayType ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Delay type. " 
SYNTAX BITS 

{ 

immediate (0) , 

synchronized (1) 



PsigType ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Psig type. " 
SYNTAX BITS 



{ 

sig(O) , 
psig (1) , 
psisig (2) 



CaDescInsMode ::= 
STATUS current 



TEXTUAL-CONVENTION 
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DESCRIPTION 

" Conditional Access Descriptor Insertion Type. 
SYNTAX BITS 

{ 

psig_insertion (0) , 

no_psig_insertion (1 ) 



FlowType ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Type of Flow: EMM, ECM, or private data. " 
SYNTAX BITS 

{ 

ecm (0) , 
emm ( 1 ) , 
private_data (2) 
} 



simMIBObjects OBJECT IDENTIFIER: : = {simMIB 1} 

simMIBConformance OBJECT IDENTIFIER: : = {simMIB 2} 



simldent OBJECT IDENTIFIER 

simECMG OBJECT IDENTIFIER 



{simMIBObjects 1} 
{simMIBObjects 2} 
{simMIBObjects 3} 



simEMMG OBJECT IDENTIFIER: 

simCPSI OBJECT IDENTIFIER: : = {simMIBObjects 4} 

simPSI OBJECT IDENTIFIER: : = {simMIBObjects 5} 

— Ident Group - This group is used for software configuration management of all Simulcrypt 
components 

— and includes the following objects: 

simSofwareVersion OBJECT-TYPE 

SYNTAX DisplayString (SIZE (80)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This contains a display string that defines the current version 
of the software for this unit. " 
: := { simldent 1 } 

simMIBVersion OBJECT-TYPE 

SYNTAX DisplayString (SIZE (80)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This contains a display string that defines the current version 
of the MIB. " 
: : = { simldent 2 } 

simMIBPrivateVersion OBJECT-TYPE 

SYNTAX DisplayString (SIZE (80)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This contains a display string that defines the current private 
version of the MIB. " 
: : = { simldent 3 } 

simAgentVersion OBJECT-TYPE 

SYNTAX DisplayString (SIZE (80)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This contains a display string that defines the current version 
of the agent. " 
: : = { simldent 4 } 



— ECM Generator Group - This group is used for configuration management and status monitoring of 

— ECM Generators. It identifies each one of the ECM Generators by the IP Address and TCP/UDP Port 

— Number. It also associates Super„CAS„ids, ECM_channel__ids, and ECM_stream__ids with ECM 

— Generators. It also associates status information and statistics with channels and streams. The 
ECM 

— Generator Group consists of three conceptual tables. The first table is the interconnection table 
and is 

— used for the Head-end Network Manager to query the IP addresses and the port number to be used by 
an 

— SCS to create a channel. It is indexed by a unique Ecmglndex which is an integer assigned by the 
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— ECMG agent : 

simEcmgTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimEcmgEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table specifies the IP addresses and Port numbers of ECM Generators 
to be used by head-end managers to configure SCSs. This table is to be 
used in ECM Generators and ECM Generator proxies . " 
: := {simECMG 1} 

SimEcmgEntry OBJECT-TYPE 

SYNTAX SimEcmgEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. Depending on whether 
this is an ECMG agent or ECMG proxy agent different table entries can 
be omitted. " 
INDEX {simEcmglndex} 
::= {simEcmgTable 1} 

SimEcmgEntry : := SEQUENCE { 

simEcmglndex INTEGER (0.. 65535), 

simEcmglpAddress IpAddress, 
simEcmgTcpPort INTEGER (0.. 65535), 

simEcmgSuCasId ECMGSuCasId, 

simEcmgChannels Counter32, 
simEcmgCwPrs Counter 32, 

simEcmgErrs Counter 32, 
simEcmgTargetCpsig INTEGER (0.. 65535), 
simEcmgCaMib OBJECT IDENTIFIER 



simEcmglndex OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The ECM Generator Table unique index. " 
::= {SimEcmgEntry 1} 

SimEcmglpAddress OBJECT-TYPE 
SYNTAX IpAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

IP address of the host of the ECMG. " 
::= {SimEcmgEntry 2} 

SimEcmgTcpPort OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

TCP port of the ECMG. " 
::= {SimEcmgEntry 3} 

SimEcmgSuCasId OBJECT-TYPE 
SYNTAX ECMGSuCasId 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The Super_VAS_id is formed by concatenation of the CA_system_id 
(15 bit) and the CA_subsystem_id (16 bit) . It defines uniquely a 
set of ECMGs for a given SCS . " 
::= {SimEcmgEntry 4} 

SimEcmgChannels OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The total number of channels this ECMG is currently maintaining. 
::= {SimEcmgEntry 5} 

SimEcmgCwPrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
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" The total number of CW provisioning requests received by this ECMG. " 
::= { simEcmgEntry 6} 

simEcmgErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of communications errors for this ECMG. " 
::= {simEcmgEntry 7} 

simEcmgTargetCpsig OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

The index into the C(P)SIG table identifying the C(P)SIG associated with this ECMG. 
::= {simEcmgEntry 8} 

simEcmgCaMib OBJECT-TYPE 

SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The pointer to a provider proprietary MIB (like ifSpecific in 
the interfaces group of MIB II. " 
::= {simEcmgEntry 9} 

— ECMG Channel Table - Used for monitoring channel information. It is indexed 

— by the ECMG Index from the ECMG table and the Channelld. 

simEcmgCTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimEcmgCEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table specifies information relating to ECMG/SCS channels including 
the IP addresses and Port numbers of SCSs communicating 
with the ECMG Generators. " 
: := {simECMG 2} 

SimEcmgCEntry OBJECT-TYPE 

SYNTAX SimEcmgCEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. Depending on whether 
this is an ECMG agent or ECMG proxy agent different table entries can 
be omitted. " 

INDEX { simEcmglndex, simEcmgChannelld} 
: := {simEcmgCTable 1} 

SimEcmgCEntry: := SEQUENCE { 

SimEcmgChannelld ECMGChannelld, 
simEcmgCScsIpAddress IpAddress, 

simEcmgCScsTcpPort INTEGER (0.. 65535), 

simEcmgCStreams Counter32, 

simEcmgCCwPrs Counter32, 

simEcmgCErrs Counter32 



SimEcmgChannelld OBJECT-TYPE 

SYNTAX ECMGChannelld 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

The ECMG/SCS Channel identifier. " 
::= {SimEcmgCEntry 1} 

SimEcmgCScsIpAddress OBJECT-TYPE 
SYNTAX IpAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" IP address of the SCS . " 
::= {SimEcmgCEntry 2} 

SimEcmgCScsTcpPort OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
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MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" TCP port of the SCS . " 
::= { simEcmgCEntry 3} 

simEcmgCStreams OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The total number of streams this ECMG is currently maintaining on this channel. " 
::= {simEcmgCEntry 4} 

simEcmgCCwPrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The total number of CW provisioning requests received by this ECMG on this channel. 
::= {simEcmgCEntry 5} 

simEcmgCErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of communications errors for this ECMG on this channel. " 
::= {simEcmgCEntry 6} 



— ECMG Stream Table - Used for monitoring stream information. It is indexed 
by the ECMG Index from the ECMG table, the Channelld from the Channel Table 

— and the Streamld. 

simEcmgSTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimEcmgSEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table specifies information relating to ECMG/SCS streams. " 
: := {simECMG 3} 

SimEcmgSEntry OBJECT-TYPE 

SYNTAX SimEcmgSEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. Depending on whether 
this is an ECMG agent or ECMG proxy agent different table entries can 
be omitted. " 

INDEX { simEcmglndex, simEcmgChannelld, simEcmgStreamId} 
: := {simEcmgSTable 1} 

SimEcmgSEntry: := SEQUENCE { 

SimEcmgStreamId ECMGStreamId, 
simEcmgEcmId ECMGStreamId, 
simEcmgSLastCp Unsigned32, 
simEcmgSCwPrs Counter 32, 

simEcmgSErrs Counter32 



SimEcmgStreamId OBJECT-TYPE 

SYNTAX ECMGStreamId 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

The ECMG/SCS Stream identifier. " 
::= {SimEcmgSEntry 1} 

SimEcmgEcmId OBJECT-TYPE 

SYNTAX ECMGStreamId 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The unique ECM flow identifier. " 
::= {SimEcmgSEntry 2} 

SimEcmgSLastCp OBJECT-TYPE 
SYNTAX Unsigned32 
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MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The number of the crypto period last processed on this stream. " 
::= { simEcmgSEntry 3} 

simEcmgSCwPrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of CW provisioning requests received by this ECMG on this stream. " 
::= {simEcmgSEntry 4} 

simEcmgSErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The total number of communications errors for this ECMG on this stream. " 
::= {simEcmgSEntry 5} 

— EMM/PD Generator Group - This group is used for management of EMM/PD Generators. It identifies 
each one of the EMM/PD Generators by the IP Address and TCP/UDP Port Number. It also associates 

— client_ids, data_stream_ids, and data_channel_ids with EMM/PD Generators. It also associates 

— status information and statistics with streams. The EMMG/PDG Generator Group consists of four 
conceptual tables. The first table is used for information relevant to EMMG/PDG and is indexed 

by a 

— unique EmOrPdIndex which is assigned by the EMMG/PDG agent: 

simEmOrPdTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimEmOrPdEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table defines the EMMG or PDG interfaces to the Mux and is to be 
used in EMMGs/PDGs and optionally the multiplexer. " 
: := {simEMMG 1} 

SimEmOrPdEntry OBJECT-TYPE 

SYNTAX SimEmOrPdEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. Depending on whether 
this is an EMMG/PDG or multiplexer agent different table entries can 
be omitted. " 

INDEX {simEmOrPdIndex} 
::= { SimEmOrPdTable 1} 

SimEmOrPdEntry: := SEQUENCE { 

SimEmOrPdIndex INTEGER (0.. 65535), 
simEmOrPdDataType EMMGDataType, 
simEmOrPdClientId EMMGClientId, 
simEmOrPdCommCapability EMMGCommCapability, 
simEmOrPdErrs Counter 32, 

simEmOrPdTargetCpsig INTEGER (0.. 65535), 
simEmOrPdCaMib OBJECT IDENTIFIER 
} 

SimEmOrPdIndex OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Unique index into the EMMG or PDG table. " 
: := {SimEmOrPdEntry 1} 

SimEmOrPdDataType OBJECT-TYPE 
SYNTAX EMMGDataType 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Data_type: Type of data handled by this EMMG/PDG. " 
: := {SimEmOrPdEntry 2} 

SimEmOrPdClientId OBJECT-TYPE 
SYNTAX EMMGClientId 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
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" Client„id: The client_id is a 32-bit identifier. It shall 
identify uniquely an EMMG/PDG across all the EMMGs/PDGs 
connected to a given MUX. To facilitate uniqueness of this 
value, the following rules apply: 

* In the case of EMMs or other CA related data, the two first 
bytes of the client_id should be equal to the two bytes of 
the corresponding CA_system_id. 

* In other cases a value allocated by DVB for this purpose 
should be used. " 

: := {simEmOrPdEntry 3} 

simEmOrPdCommCapability OBJECT-TYPE 
SYNTAX EMMGCommCapability 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Communication capability between EMMG/PDG and the multiplexer. Currently 
TCP or UDP or both. " 
: := { SimEmOrPdEntry 4} 

simEmOrPdErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The total number of communications errors for this EMMG/PDG. " 
: := {SimEmOrPdEntry 5} 

simEmOrPdTargetCpsig OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

The index into the C(P)SIG table identifying the C(P)SIG associated with this EMMG/PDG. 
: := {SimEmOrPdEntry 6} 

simEmOrPdCaMib OBJECT-TYPE 

SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Pointer to a vendor proprietary extension to the EMMG/PDG MIB group. " 
: := {SimEmOrPdEntry 7} 



— EMMG/PDG Logical Access Point Table - The second EMM Generator/ PD Genartor table is used for 

— configuration of the EMMGs/PDGs. It is uniquely indexed by the EmOrPdLapIndex which is a 

— globally assigned quantity (with respect to the head-end) and associates globally assigned 
Logical 

— Access Points (LAPs) with mux ports. 

simEmOrPdLapTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimEmOrPdLapEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
" This table is used for configuration of EMM/PD Generators. " 
: := {simEMMG 2} 

SimEmOrPdLapEntry OBJECT-TYPE 

SYNTAX SimEmOrPdLapEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX {simEmOrPdLapIndex} 
: := { SimEmOrPdLapTable 1} 

SimEmOrPdLapEntry : := SEQUENCE { 

SimEmOrPdLapIndex INTEGER (0.. 65535), 

simEmOrPdLapAdminState AdministrativeState, 

simEmOrPdLapCommType EMMGCommType, 
simEmOrPdLapMuxIpAddress IpAddress, 

simEmOrPdLapMuxPort INTEGER (0.. 65535), 

simEmOrPdLapStatus RowStatus 
} 

SimEmOrPdLapIndex OBJECT-TYPE 
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SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Unique Lpgical Access Point (LAP) identifier. " 
::= { simEmOrPdLapEntry 1} 

simEmOrPdLapAdminState OBJECT-TYPE 
SYNTAX AdministrativeState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Used by an authorized manager to lock a conceptual row for exclusive 
write and create access. " 
: := {SimEmOrPdLapEntry 2} 

simEmOrPdLapCommType OBJECT-TYPE 
SYNTAX EMMGCommType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Type of communication between EMMG/PDG and the multiplexer. Currently 
TCP or UDP . " 
::= {simEmOrPdLapEntry 3} 

simEmOrPdLapMuxIpAddress OBJECT-TYPE 
SYNTAX IpAddress 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" IP address of the multiplexer for EMMG/PDG communication. " 
: := {SimEmOrPdLapEntry 4} 

simEmOrPdLapMuxPort OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Port number (TCP/UDP) of the multiplexer for EMMG/PDG communication. " 
::= {simEmOrPdLapEntry 5} 

simEmOrPdLapStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Used for table row creation management . " 
::= {simEmOrPdLapEntry 6} 

— EMMG/PDG Logical Access Point Group Table - The third EMM Generator/ PD Genartor table is used 

— for 

— configuration of the EMMGs/PDG. It associates LAP Groups and LAPs and is 

— uniquely indexed by the EmOrPdLapGroup, and EmOrPdLapIndex . 

simEmOrPdLapGTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimEmOrPdLapGEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
" This table is used for configuration of EMM/PD Generators. " 
: := {simEMMG 3} 

SimEmOrPdLapGEntry OBJECT-TYPE 

SYNTAX SimEmOrPdLapGEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX { simEmOrPdLapGroup, simEmOrPdLapIndex } 
::= {SimEmOrPdLapGTable 1} 

SimEmOrPdLapGEntry : := SEQUENCE { 

SimEmOrPdLapGroup INTEGER (0.. 65535), 
simEmOrPdLapGAdminState AdministrativeState, 
simEmOrPdLapGStatus RowStatus 
} 

SimEmOrPdLapGroup OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
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DESCRIPTION 
" Logical Access Point (LAP) group. " 
: := {simEmOrPdLapGEntry 1} 

simEmOrPdLapGAdminState OBJECT-TYPE 
SYNTAX AdministrativeState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Used by an authorized manager to lock a conceptual row for exclusive 
write and create access. " 
: := {SimEmOrPdLapGEntry 2} 

simEmOrPdLapGStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Used for table row creation management . " 
: := {SimEmOrPdLapGEntry 3} 

— EMMG/PDG Channel Table - Used for monitoring of EMM / PD Generator channels. 

simEmOrPdCTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimEmOrPdCEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
" This table is used for monitoring of channels between Muxes and EMMGs/PDGs. 
: := {simEMMG 4} 

SimEmOrPdCEntry OBJECT-TYPE 

SYNTAX SimEmOrPdCEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX {simEmOrPdIndex, simEmOrPdLapIndex, simEmOrPdChannelld} 
::= { SimEmOrPdCTable 1} 

SimEmOrPdCEntry: := SEQUENCE { 

SimEmOrPdChannelld EMMGChannelld, 
simEmOrPdCommType EMMGCommType, 
simEmOrPdCIpAddress IpAddress, 
simEmOrPdCPort INTEGER (0.. 65535), 
simEmOrPdCErrs Counter32 
} 

SimEmOrPdChannelld OBJECT-TYPE 
SYNTAX EMMGChannelld 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Data_channel„id: This identifier uniquely identifies a 
EMM/Private Data channel within a client_id. " 
::= {SimEmOrPdCEntry 1} 

SimEmOrPdCommType OBJECT-TYPE 
SYNTAX EMMGCommType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Communications type: TCP or UDP . " 
::= {SimEmOrPdCEntry 2} 

SimEmOrPdCIpAddress OBJECT-TYPE 
SYNTAX IpAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" IP address of the host of the EMMG or PDG. " 
::= {SimEmOrPdCEntry 3} 

SimEmOrPdCPort OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" Port number *TCP or UDP of the EMMG or PDG. " 
: := {SimEmOrPdCEntry 4} 
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simEmOrPdCErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of communications errors on this channel. 
: := {simEmOrPdCEntry 5} 



— EMMG/PDG Stream Table - Used for monitoring of EMM / PD Generator streams. 

simEmOrPdSTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimEmOrPdSEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table is used for monitoring of streams between Muxes and EMMGs/PDGs. 
: := {simEMMG 5} 

SimEmOrPdSEntry OBJECT-TYPE 

SYNTAX SimEmOrPdSEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX {simEmOrPdIndex, simEmOrPdLapIndex, simEmOrPdDatald 
} 

::= { SimEmOrPdSTable 1} 

SimEmOrPdSEntry : := SEQUENCE { 

SimEmOrPdDatald EMMGStreamId, 
simEmOrPdSChannelld EMMGChannelld, 
simEmOrPdBwidth Unsigned32, 
simEmOrPdStreamId EMMGStreamId, 
simEmOrPdSErrs Counter 32, 
simEmOrPdSBytes Counter32 
} 

SimEmOrPdDatald OBJECT-TYPE 
SYNTAX EMMGStreamId 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" DatalD: This identifier uniquely identifies a EMM/Private 
Data stream. " 
::= {SimEmOrPdSEntry 1} 

SimEmOrPdSChannelld OBJECT-TYPE 
SYNTAX EMMGChannelld 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Channel identifier. " 
::= {SimEmOrPdSEntry 2} 

SimEmOrPdBwidth OBJECT-TYPE 
SYNTAX Unsigned32 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Bandwidth. " 
::= {SimEmOrPdSEntry 3} 

SimEmOrPdStreamId OBJECT-TYPE 
SYNTAX EMMGStreamId 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Data_stream_id: This identifier uniquely identifies a EMM/Private 
Data stream within a channel . " 
: := {SimEmOrPdSEntry 4} 

SimEmOrPdSErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of communications errors on this stream. " 
: := {SimEmOrPdSEntry 5} 
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simEmOrPdSBytes OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of bytes sent by this EMMG/PDG on this stream. " 
: := {simEmOrPdSEntry 6} 

— C(P)SIG) Group - This Group is used for management of some aspects of inteaction between the 
custom PSI Generators (C(P)SIG)) and the PSI Generator. It consists of three tables. The 
first table is used for advertising C(P)SIG) information by the C(P)SIG) host. The 

second table is used for the manager to configure the C(P)SIG) . The third and fourth 

— table are used for C(P)SIG) channel and stream monitoring. 



simCpsigTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimCpsigEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table defines the C(P)SIG) interfaces to the Mux and is to be 
used in the C(P)SIG) and optionally the multiplexer. " 
: := {simCPSI 1} 

SimCpsigEntry OBJECT-TYPE 

SYNTAX SimCpsigEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. Depending on whether 
this is an EMMG/PDG or multiplexer agent different table entries can 
be omitted. " 

INDEX {simCpsiglndex} 
::= {simCpsigTable 1} 

SimCpsigEntry : := SEQUENCE { 

SimCpsiglndex INTEGER (0.. 65535), 

simCpsigSuperCasId ECMGSuCasId, 

simCpsigErrs Counter32, 

simCpsigChannels Counter32, 
simCpsigCpsiglpAddress IpAddress, 

simCpsigCpsigPort INTEGER (0. . 65535) , 

simCpsigCaMib OBJECT IDENTIFIER 
} 

SimCpsiglndex OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" Unique index into the EMMG or PDG table. " 
::= {SimCpsigEntry 1} 

SimCpsigSuperCasId OBJECT-TYPE 
SYNTAX ECMGSuCasId 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" super_CAS„id " 
::= {SimCpsigEntry 2} 

SimCpsigErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of communications errors for this C(P)SIG) . " 
::= {SimCpsigEntry 3} 

SimCpsigChannels OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of channels for this C(P)SIG). " 
::= {SimCpsigEntry 4} 

SimCpsigCpsiglpAddress OBJECT-TYPE 
SYNTAX IpAddress 
MAX-ACCESS read-only 
STATUS current 
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DESCRIPTION 

" The IP Address of the C{P)SIG). " 
::= { simCpsigEntry 5} 

simCpsigCpsigPort OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

The TCP port number of the C(P)SIG). " 
::= {simCpsigEntry 6} 

simCpsigCaMib OBJECT-TYPE 

SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Pointer to a vendor proprietary extension to the C(P)SIG) MIB group. " 
::= {simCpsigEntry 7} 

— C(P)SIG) Channel Table - Used for monitoring of C(P)SIG channels. 

simCpsigCTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimCpsigCEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table is used for monitoring of channels between (P)SIG)s and C(P)SIGs. 
: := {simCPSI 2} 

SimCpsigCEntry OBJECT-TYPE 

SYNTAX SimCpsigCEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX { simCpsiglndex, simCpsigChannelld) 
::= {simCpsigCTable 1} 

SimCpsigCEntry: := SEQUENCE { 

SimCpsigChannelld INTEGER (0.. 65535), 
simCpsigPsiglpAddress IpAddress, 
simCpsigPsigPort INTEGER (0.. 65535), 
simCpsigCErrs Counter32, 

simCpsigCTstrms Counter 32, 
simCpsigCSstrms Counter32 
} 

SimCpsigChannelld OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Channel id identifies the C(P)SI channel. " 
::= {SimCpsigCEntry 1} 

SimCpsigPsiglpAddress OBJECT-TYPE 
SYNTAX IpAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

IP address of the host of the (P)SIG). " 
::= {SimCpsigCEntry 2} 

SimCpsigPsigPort OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

TCP Port number of the (P)SIG). " 
::= {SimCpsigCEntry 3} 

SimCpsigCErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The total number of communications errors on this channel. " 
::= {SimCpsigCEntry 4} 

SimCpsigCTstrms OBJECT-TYPE 
SYNTAX Counter32 
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MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of transport streams on this channel. " 
::= { simCpsigCEntry 5} 

simCpsigCSstrms OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The total number of session on this streamschannel . " 
::= {simCpsigCEntry 6} 



— C(P)SIG Stream Table - Used for monitoring of C(P)SIG) streams. 

simCpsigStreamTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimCpsigStreamEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table is used for monitoring of streams between Muxes and C(P)SIG)s. " 
: := {simCPSI 3} 

SimCpsigStreamEntry OBJECT-TYPE 

SYNTAX SimCpsigStreamEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX { simCpsiglndex, simCpsigChannelld, simCpsigStreamId} 
::= {simCpsigStreamTable 1} 

SimCpsigStreamEntry: := SEQUENCE { 

SimCpsigStreamId INTEGER (0.. 65535), 
simCpsigStreamTStreamId INTEGER (0.. 65535), 
simCpsigStreamNid INTEGER (0.. 65535), 
simCpsigStreamOnid INTEGER (0.. 65535), 
simCpsigStreamMaxCompTime INTEGER (0 . . 65535) , 
simCpsigStreamTrigger Enable Trigger Type, 
simCpsigStreamLa St Trigger Trigger Type, 
simCpsigStreamLastEventId INTEGER (0.. 65535), 
simCpsigStreamLastServiceld INTEGER (0.. 65535), 
simCpsigStreamLastEsId INTEGER (0.. 65535), 
simCpsigStreamLastEcmPid INTEGER (0.. 65535), 
simCpsigStreamErrs Counter32, 
simCpsigStreamBytes Counter32 
} 

SimCpsigStreamId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This identifier uniquely identifies a C(P)SIG) stream " 
::= {SimCpsigStreamEntry 1} 

SimCpsigStreamTStreamId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" This identifier uniquely identifies a C(P)SIG transport stream " 
::= {SimCpsigStreamEntry 2} 

SimCpsigStreamNid OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" This identifier uniquely identifies the network ide associated with the stream " 
::= {SimCpsigStreamEntry 3} 

SimCpsigStreamOnid OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" This identifier uniquely identifies the original network ide associated with the stream 
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{ simCpsigStreamEntry 4} 



simCpsigStreamMaxCompTime OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Max Computation time by the C{P)SIG. 
::= {simCpsigStreamEntry 5} 



simCpsigStreamTrigger Enable OBJECT-TYPE 
SYNTAX TriggerType 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Triggers enabled by the C(P)SIG. " 
::= {SimCpsigStreamEntry 6} 



simCpsigStreamLast Trigger OBJECT-TYPE 
SYNTAX TriggerType 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" Last trigger processed by the C(P)SIG. 
::= {simCpsigStreamEntry 7} 



SimCpsigStreamLast Event Id OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Last event id processed by the C(P)SIG. " 
::= {simCpsigStreamEntry 8} 

SimCpsigStreamLast Service Id OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Last service id processed by the C(P)SIG. 
::= {simCpsigStreamEntry 9} 



simCpsigStreamLastEsId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Last elementary stream id processed by the C(P)SIG. " 
::= {simCpsigStreamEntry 10} 



simCpsigStreamLastEcmPid OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

Last ECM pid processed by the C(P)SIG. " 
::= {simCpsigStreamEntry 11} 

simCpsigStreamErrs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of communications errors on this stream. " 
::= {simCpsigStreamEntry 12} 

simCpsigStreamBytes OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" The total number of bytes sent by this EMMG/PDG on this stream. 
::= {simCpsigStreamEntry 13} 



(P)SIG Group - This Group is used for the synchronization and information 
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exchange between the PSI Generator and Custom PSI Generators and 
between the SI Generator and Custom SI Generators. 



simPsigTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
" This table advertises the (P)SIG configuration information. 
: := {simPSI 1} 

SimPsigEntry OBJECT-TYPE 

SYNTAX SimPsigEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX {simPsiglndex} 
: := {simPsigTable 1} 

SimPsigEntry : := SEQUENCE { 

simPsiglndex INTEGER (0.. 65535), 
simPsigType PsigType, 
simPsigTrigger Support Trigger Type, 
simPsigNetworkId INTEGER (0.. 65535), 
simPsigONetworkId INTEGER (0.. 65535), 
simPsigTransStreamId INTEGER (0.. 65535), 
simPsigTSServices OCTET STRING (SIZE (0 .. 511 ) ) 



simPsiglndex OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The unique index into the table. 
::= {SimPsigEntry 1} 

SimPsigType OBJECT-TYPE 
SYNTAX PsigType 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Psig type " 
::= {SimPsigEntry 2} 



SimPsigTrigger Support OBJECT-TYPE 
SYNTAX TriggerType 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Identifies which trigger types the PSIG supports. 
::= {SimPsigEntry 3 } 



SimPsigNetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Network identifier. " 
::= {SimPsigEntry 4} 

SimPsigONetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Original Network identifier. 
::= {SimPsigEntry 5} 



SimPsigTransStreamId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" Transport Stream identifier. 
::= {SimPsigEntry 6} 



£75/ 



161 



ETSI TS 103 197 VI. 1.1 (2000-06) 



simPsigTSServices OBJECT-TYPE 

SYNTAX OCTET STRING (SI ZE ( . . 51 1 ) ) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" List of service identifies on the transport stream. 
::= { simPsigEntry 7} 



simPsigConfigTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigConf igEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
" This table configures the (P) SIG/ (C) PSIG communication. 
: := {simPSI 2} 



simPsigConfigEntry OBJECT-TYPE 

SYNTAX SimPsigConfigEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX { simPsigConf igCustCasId, simPsigConf iglndex 
::= {simPsigConfigTable 1} 



simPs iglndex } 



SimPsigConfigEntry: := SEQUENCE { 
SimPsigConf iglndex 
SimPsigConf igAdminSt ate 
SimPsigConf igCpsigType 
simPsigConf igCustCas Id 
simPsigConf igMaxCompTime 
simPsigConf igServi eel d 
simPsigConf igTrigger Enable 
simPsigConfigCADInsMode 
simPsigConf igEntryStatus 
} 



INTEGER (0. . 65535) , 

AdministrativeState, 
PsigType, 
ECMGSuCasId, 
INTEGER(0. . 65535) , 
INTEGER (0. . 65535) , 

TriggerType, 
CaDescInsMode, 
RowStatus 



simPsigConfiglndex OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
" The unique index into the table. " 
::= {simPsigConfigEntry 1} 

SimPsigConf igAdminSt ate OBJECT-TYPE 
SYNTAX AdministrativeState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Used by an authorized manager to lock a conceptual row for exclusive 
write and create access. " 
::= {simPsigConfigEntry 2} 

SimPsigConf igCpsigType OBJECT-TYPE 
SYNTAX PsigType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" C(P)SIG type. " 
::= {simPsigConfigEntry 3} 

simPsigConfigCustCasId OBJECT-TYPE 
SYNTAX ECMGSuCasId 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Custom CAS Identifier. " 
::= {simPsigConfigEntry 4} 

SimPsigConf igMaxCompTime OBJECT-TYPE 
SYNTAX INTEGER (0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Maximum Computing Time. " 
::= {simPsigConfigEntry 5} 

simPsigConfigServiceld OBJECT-TYPE 
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SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Service identifier. " 
::= { simPsigConf igEntry 6} 

simPsigConfigTrigger Enable OBJECT-TYPE 
SYNTAX TriggerType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Trigger types enabled. " 
::= { simPsigConf igEntry 7} 

SimPsigConf igCADInsMode OBJECT-TYPE 
SYNTAX CaDescInsMode 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Conditional Access Descriptor Insert mode. 
::= { simPsigConf igEntry 8} 



SimPsigConf igEntry Status OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Used for table row creation management . 
::= { simPsigConf igEntry 9} 



simPsigEcmTrTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigEcmTrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
" This table contains all the active ECM Triggers. 
: := {simPSI 3} 



SimPsigEcmTrEntry OBJECT-TYPE 

SYNTAX SimPsigEcmTrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table 
INDEX {simPsigEcmTrlndex} 
: := {SimPsigEcmTrTable 1} 



entry. 



SimPsigEcmTrEntry : := SEQUENCE { 

SimPsigEcmTrlndex INTEGER (0.. 65535), 
simPsigEcmTrNetworkId INTEGER (0.. 65535), 
simPsigEcmTrONetworkId INTEGER (0.. 65535), 
simPsigEcmTrTransStreamId INTEGER (0.. 65535), 



simPsigEcmTr Service Id 

simPsigEcmTrEsId 

SimPsigEcmTr Type 

simPsigEcmTrSuCasId 

simPsigEcmTrEcmId 

simPsigEcmTrEcmPid 



INTEGER (0. . 65535) , 
INTEGER (0. . 65535) , 
ECMTriggerType, 

ECMGSuCasId, 
ECMGStreamId, 
INTEGER (0. . 65535) , 



simPsigEcmTrAccessCriteria OCTET STRING (SIZE (0 .. 127 ) ) 



SimPsigEcmTrlndex OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" The trigger index. " 
::= {SimPsigEcmTrEntry 1} 

SimPsigEcmTrNetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The Network Identifier. " 
::= {SimPsigEcmTrEntry 2} 

SimPsigEcmTrONetworkId OBJECT-TYPE 
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SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The Original Network Identifier. 
::= { simPsigEcmTrEntry 3} 

simPsigEcmTrTransStreamId OBJECT-TYPE 
SYNTAX INTEGER (0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Transport Stream Identifier. " 
::= {simPsigEcmTrEntry 4} 

simPsigEcmTr Service Id OBJECT-TYPE 
SYNTAX INTEGER ( 0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Service Identifier. " 
::= {simPsigEcmTrEntry 5} 

simPsigEcmTrEsId OBJECT-TYPE 
SYNTAX INTEGER (0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Elementary Stream Identifier. " 
::= {SimPsigEcmTrEntry 6} 

simPsigEcmTrType OBJECT-TYPE 
SYNTAX ECMTriggerType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" ECM Trigger Type. " 
::= {SimPsigEcmTrEntry 7} 

simPsigEcmTrSuCasId OBJECT-TYPE 
SYNTAX ECMGSuCasId 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" ECM Client Identifier. 
::= {simPsigEcmTrEntry 8} 

simPsigEcmTrEcmId OBJECT-TYPE 
SYNTAX ECMGStreamId 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" ECM Stream Identifier. " 
::= {simPsigEcmTrEntry 9} 

simPsigEcmTrEcmPid OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" ECM PID " 
: := {SimPsigEcmTrEntry 10} 

simPsigEcmTrAccessCriteria OBJECT-TYPE 
SYNTAX OCTET STRING (SI ZE ( . . 12 7 ) ) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Access criteria. " 
::= {simPsigEcmTrEntry 11} 



simPsigFlowTrTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigFlowTrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table contains all the active Flow Triggers . 
: := {simPSI 4} 



SimPsigFlowTrEntry OBJECT-TYPE 
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SYNTAX SimPsigFlowTrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table 
INDEX {simPsigFlowTrlndex} 
: := {simPsigFlowTrTable 1} 



entry. 



SimPsigFlowTrEntry: := SEQUENCE { 
simPsigFlowTrlndex 
simPsigFlowTrType 
simPsigFlowTrSuCasId 
simPsigFlowTrFlowId 
simPsigFlowTrFlowPID 



INTEGER (0. . 65535) , 
FlowType, 

FlowSuCasId, 
Flowld, 

INTEGER (0. . 65535) 



SimPsigFlowTrlndex OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The trigger index. " 
::= {SimPsigFlowTrEntry 1} 

SimPsigFlowTrType OBJECT-TYPE 
SYNTAX FlowType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Flow Type. " 
::= {SimPsigFlowTrEntry 2} 

SimPsigFlowTrSuCasId OBJECT-TYPE 
SYNTAX FlowSuCasId 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Flow Super CAS identifier. 
::= {SimPsigFlowTrEntry 3} 

SimPsigFlowTrFlowId OBJECT-TYPE 
SYNTAX Flowld 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Flow Stream Identifier. " 
: := {SimPsigFlowTrEntry 4} 

SimPsigFlowTrFlowPID OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Flow PID " 
::= {SimPsigFlowTrEntry 5} 



simPsigEvntTrTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigEvntTrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
" This table contains all the active EVNT Triggers. 
: := {simPSI 5} 

SimPsigEvntTrEntry OBJECT-TYPE 

SYNTAX SimPsigEvntTrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX {simPsigEvntTrlndex} 
: := {SimPsigEvntTrTable 1} 



SimPsigEvntTrEntry: := SEQUENCE { 
SimPsigEvntTrlndex 
simPsigEvntTrNetworkId 
simPsigEvntTrONetworkId 
simPsigEvntTrTransStreamId 
simPsigEvntTr Service Id 
simPsigEvntTr Event Id 



INTEGER (0. . 65535) , 



INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 



.65535) , 
.65535) , 
.65535) , 
.65535) , 
.65535) , 
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simPsigEvntTrStartTime OCTET STRING (SIZE (0..4)), 
simPsigEvntTrDuration OCTET STRING(SIZE (0..2)), 
simPsigEvntTrPrivateData OCTET STRING(SIZE (0..256)) 



simPsigEvntTrlndex OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" The event trigger index. " 
::= { simPsigEvntTrEntry 1} 

simPsigEvntTrNetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The Network Identifier. " 
::= {simPsigEvntTrEntry 2} 

simPsigEvntTrONetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The Original Network Identifier. 
::= {simPsigEvntTrEntry 3} 

simPsigEvntTrTransStreamId OBJECT-TYPE 
SYNTAX INTEGER ( 0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Transport Stream Identifier. " 
: := {SimPsigEvntTrEntry 4} 

simPsigEvntTr Service Id OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Event trigger service identifier. 
::= {SimPsigEvntTrEntry 5} 

simPsigEvntTrEventId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Event Identifier. " 
::= {SimPsigEvntTrEntry 6} 

SimPsigEvntTrStartTime OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (0..4)) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Event start time. " 
::= {simPsigEvntTrEntry 7} 

SimPsigEvntTrDuration OBJECT-TYPE 

SYNTAX OCTET STRING(SIZE (0..2)) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Event duration. " 
: := {SimPsigEvntTrEntry 8} 

SimPsigEvntTrPrivateData OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (0..256)) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" EVNT Channel Identifier. 
: := {SimPsigEvntTrEntry 9} 



simPsigDescInsTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigDescInsEntry 
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MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table contains all the information related to descriptor insertion. 
: := {simPSI 6} 

simPsigDescInsEntry OBJECT-TYPE 

SYNTAX SimPsigDescInsEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX { simPsigDescInsIndex} 
::= { simPsigDescInsTable 1} 

SimPsigDescInsEntry : := SEQUENCE { 

SimPsigDescInsIndex INTEGER (0.. 65535), 
simPsigDescInsAdminState AdministrativeState, 
simPsigDescInsTrlndex INTEGER (0.. 65535), 
simPsigDescInsTrType Trigger Type, 
simPsigDescInsLocationId Insert Location, 
simPsigDescInsNetworkId INTEGER (0.. 65535), 
simPsigDescInsONetworkId INTEGER (0.. 65535), 
simPsigDescInsTransStreamId INTEGER (0.. 65535), 
simPsigDescInsServiceld INTEGER (0.. 65535), 
simPsigDescInsElmStreamId INTEGER (0.. 65535), 
simPsigDescInsBouquetId INTEGER (0.. 65535), 
simPsigDescInsEventId INTEGER (0.. 65535), 
simPsigDescInsONetworkId21oop INTEGER (0.. 65535), 
simPsigDescInsNetworkldOther INTEGER (0.. 65535), 
simPsigDescInsTransStreamId20rO INTEGER (0.. 65535), 
simPsigDescInsDelayType Del ay Type, 
simPsigDescInsDelay OCTET STRING (SIZE (0 . . 1) ) , 
simPsigDescPrivDataSpfier INTEGER (0.. 65535), 
simPsigDescInsEntryStatus RowStatus 
} 

SimPsigDescInsIndex OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The unique index into the table. " 
::= {simPsigDescInsEntry 1} 

SimPsigDescInsAdminState OBJECT-TYPE 
SYNTAX AdministrativeState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Used by an authorized manager to lock a conceptual row for exclusive 
write and create access. " 
::= {simPsigDescInsEntry 2} 

SimPsigDescInsTrlndex OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The unique index into the corresponding trigger table. " 
::= {simPsigDescInsEntry 3} 

SimPsigDescInsTrType OBJECT-TYPE 
SYNTAX TriggerType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The type of the trigger that caused this descriptor insert. " 
::= {simPsigDescInsEntry 4} 

SimPsigDescInsLocationId OBJECT-TYPE 
SYNTAX InsertLocation 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The type of target table for insertion. " 
::= {simPsigDescInsEntry 5} 

SimPsigDescInsNetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
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MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The Network Identifier. " 
::= { simPsigDescInsEntry 6} 

simPsigDescInsONetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The Original Network Identifier. " 
::= {SimPsigDescInsEntry 7} 

simPsigDescInsTransStreamId OBJECT-TYPE 
SYNTAX INTEGER (0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Transport Stream Identifier. " 
::= {SimPsigDescInsEntry 8} 

simPsigDescInsServiceld OBJECT-TYPE 
SYNTAX INTEGER (0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Service Identifier. " 
::= {simPsigDescInsEntry 9} 

simPsigDescInsElmStreamId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Elementary stream identifier. " 
::= {simPsigDescInsEntry 10} 

simPsigDescInsBouquetId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Event trigger bouquet identifier. " 
::= {SimPsigDescInsEntry 11} 

simPsigDescInsEventId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" EVNT Identifier. 
::= {SimPsigDescInsEntry 12} 

simPsigDescInsONetworkId21oop OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The Original Network Identifier second loop. " 
::= {simPsigDescInsEntry 13} 

simPsigDescInsNetworkldOther OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The Network Identifier other. " 
::= {simPsigDescInsEntry 14} 

simPsigDescInsTransStreamId20rO OBJECT-TYPE 
SYNTAX INTEGER (0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Transport Stream Identifier second loop or other. 
::= {simPsigDescInsEntry 15} 

simPsigDescInsDelayType OBJECT-TYPE 
SYNTAX DelayType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
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" Delay type, immediate or synchronized. 
::= { simPsigDescInsEntry 16} 

simPsigDescInsDelay OBJECT-TYPE 

SYNTAX OCTET STRING {SIZE{0..1)) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Insert delay " 
::= {simPsigDescInsEntry 17} 

simPsigDescPrivDataSpfier OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Private data specifier " 
::= {simPsigDescInsEntry 18} 

simPsigDescInsEntryStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Other Transport Stream identifiers. " 
::= {SimPsigDescInsEntry 19} 



simPsigDescInsDescTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigDescInsDescEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table contains all the descriptors to be inserted. " 
: := {simPSI 7} 

SimPsigDescInsDescEntry OBJECT-TYPE 

SYNTAX SimPsigDescInsDescEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX { simPsigDescInsIndex, simPsigDescInsDescIndex } 
::= {simPsigDescInsDescTable 1} 

SimPsigDescInsDescEntry : := SEQUENCE { 

SimPsigDescInsDescIndex INTEGER (0.. 65535), 
simPsigDescInsDescAdminState AdministrativeState, 
simPsigDescInsDescriptor OCTET STRING (SIZE (0 .. 8191) ) , 
simPsigDescInsDescriptorStatus Descriptor Status, 
simPsigDescInsDescEntryStatus RowStatus 
} 



SimPsigDescInsDescIndex OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The unique index into the table. 
::= {SimPsigDescInsDescEntry 1} 



SimPsigDescInsDescAdminState OBJECT-TYPE 
SYNTAX AdministrativeState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Used by an authorized manager to lock 
write and create access. " 
::= {SimPsigDescInsDescEntry 2} 



a conceptual row for exclusive 



SimPsigDescInsDescriptor OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE ( . . 81 91 ) ) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The descriptor to be inserted. " 
::= {SimPsigDescInsDescEntry 3} 

SimPsigDescInsDescriptorStatus OBJECT-TYPE 
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SYNTAX DescriptorStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The insertion status of the descriptor. 
::= { simPsigDescInsDescEntry 4} 

simPsigDescInsDescEntry Status OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Other transport stream identifiers. " 
::= {simPsigDescInsDescEntry 5} 



simPsigTblProvTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigTblProvEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This table is the interface to obtaining all PSI/SI information. 
: := {simPSI 8} 

SimPsigTblProvEntry OBJECT-TYPE 

SYNTAX SimPsigTblProvEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX {simPsigTblProvIndex} 
: := {SimPsigTblProvTable 1} 



SimPsigTblProvEntry: := SEQUENCE { 
SimPsigTblProvIndex 
SimPsigTblProvTable Id 
simPsigTblNetworkId 
simPsigTblONetworkId 
simPsigTblTransStreamId 
simPsigTbl Service Id 
simPsigTblBouquetId 
simPsigTblEventId 
simPsigTblONetworkId21oop 
simPsigTblNetworkldOther 



INTEGER (0. . 65535) , 

ProvTableld, 
INTEGER (0. . 65535) , 

INTEGER (0. . 65535) , 
INTEGER (0. . 65535) , 
INTEGER (0. . 65535) , 
INTEGER (0. . 65535) , 
INTEGER (0. . 65535) , 

INTEGER (0. . 65535) , 
INTEGER (0. . 65535) , 



simPsigTblTransStreamId20rO INTEGER (0.. 65535), 
simPsigTblSegmentNr INTEGER (0.. 65535), 
simPsigTblProvPart OCTET STRING (SIZE (0 . . 81 91 ) ) , 
simPsigTblProvPartNumber INTEGER (0.. 65535) 



SimPsigTblProvIndex OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The unique index into the table. " 
: := {SimPsigTblProvEntry 1} 

simPsigTblProvTableld OBJECT-TYPE 
SYNTAX ProvTableld 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The table identifier of the table. 
: := {SimPsigTblProvEntry 2} 

SimPsigTblNetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The Network Identifier. " 
: := {SimPsigTblProvEntry 3} 

SimPsigTblONetworkId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" The Original Network Identifier. " 
: := {SimPsigTblProvEntry 4} 
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simPsigTblTransStreamId OBJECT-TYPE 
SYNTAX INTEGER (0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Transport Stream Identifier. " 
::= { simPsigTblProvEntry 5} 

simPsigTblServiceld OBJECT-TYPE 
SYNTAX INTEGER ( 0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Service Identifier. " 
::= {simPsigTblProvEntry 6} 

simPsigTblBouquetId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Event trigger bouquet identifier. " 
: := {SimPsigTblProvEntry 7} 

simPsigTblEventId OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Event Identifier " 
: := {SimPsigTblProvEntry 8} 

simPsigTblONetworkId21oop OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The Original Network Identifier second loop. " 
: := {SimPsigTblProvEntry 9} 

simPsigTblNetworkldOther OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The Network Identifier other. " 
: := {SimPsigTblProvEntry 10} 

simPsigTblTransStreamId20rO OBJECT-TYPE 
SYNTAX INTEGER (0. . 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Transport Stream Identifier second loop or other. " 
: := {SimPsigTblProvEntry 11} 

simPsigTblSegmentNr OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Segment Number " 
: := {SimPsigTblProvEntry 12} 

simPsigTblProvPart OBJECT-TYPE 

SYNTAX OCTET STRING (SI ZE ( . . 81 91 ) ) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Event Identifier " 
: := {SimPsigTblProvEntry 13} 

simPsigTblProvPartNumber OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Each table is subdivided into parts for SNMP transport if necessary. 
The part number identifies the table part of this entry. " 
: := {SimPsigTblProvEntry 14} 
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simPsigPIDProvTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SimPsigPIDProvEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" This is the PID provisioning table. " 
: := {simPSI 9} 

SimPsigPIDProvEntry OBJECT-TYPE 

SYNTAX SimPsigPIDProvEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

" Information about a single table entry. " 
INDEX {simPsigPIDProvSuCasId, simPsigPIDProvFlowId} 
: := {simPsigPIDProvTable 1} 

SimPsigPIDProvEntry: := SEQUENCE { 

simPsigPIDProvFlowType FlowType, 
SimPsigPIDProvSuCasId FlowSuCasId, 

SimPsigPIDProvFlowId Flowld, 

simPsigPIDProvFlowPID INTEGER (0.. 65535) 



SimPsigPIDProvFlowType OBJECT-TYPE 
SYNTAX FlowType 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" Flow Type. " 
::= {SimPsigPIDProvEntry 1} 

SimPsigPIDProvSuCasId OBJECT-TYPE 
SYNTAX FlowSuCasId 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" Flow Super CAS identifier. 
::= {SimPsigPIDProvEntry 2} 

SimPsigPIDProvFlowId OBJECT-TYPE 
SYNTAX Flowld 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" Flow Stream Identifier. " 
::= {SimPsigPIDProvEntry 3} 

SimPsigPIDProvFlowPID OBJECT-TYPE 
SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
" Flow PID " 
: := {SimPsigPIDProvEntry 4} 



Conformance Information 



simCompliances OBJECT IDENTIFIER: : = { simMIBConf ormance 1} 
simGroups OBJECT IDENTIFIER: : = { simMIBConf ormance 2} 

simEcmgCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent ECMGs " 
MODULE — this module 

MANDATORY-GROUPS { simldentGroup, simEcmgGroup } 
::= {simCompliances 1} 

simEmOrPdCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent EMMGs or PDGs " 
MODULE — this module 
MANDATORY-GROUPS {simldentGroup, simEmOrPdGroup } 
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GROUP simEmOrPdLapGGroup 
DESCRIPTION 

" Allows for grouping of LAPs " 
::= { simCompliances 2} 

simCpsigCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent C(P)SIG)s " 
MODULE — this module 

MANDATORY-GROUPS { simldentGroup, simCpsigGroup } 
::= {simCompliances 3} 

simPsigCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent (P)SIG)s " 
MODULE — this module 

MANDATORY-GROUPS {simldentGroup, simPsigGroup } 
::= {simCompliances 4} 

simldentGroup OBJECT-GROUP 
OBJECTS { 

simSofwareVersion, 

simMIBVersion, 

simMIBPrivateVersion, 

simAgentVersion 
} 

STATUS current 
DESCRIPTION 

" A collection of objects providing software configuration infomation. 
: := { simGroups 1 } 

simEcmgGroup OBJECT-GROUP 
OBJECTS { 
simEcmg Index, 
simEcmglpAddress, 
simEcmgTcpPort, 
simEcmgSuCasId, 
simEcmgChannels, 
simEcmgCwPrs, 
simEcmgErrs, 
simEcmgTargetCpsig, 
simEcmgCaMib , 
simEcmgChannelld, 
simEcmgCScsIpAddress, 
simEcmgCScsTcpPort, 
simEcmgCSt reams, 
simEcmgCCwPrs, 
simEcmgCErrs, 
simEcmgStreamId, 
simEcmgEcmId, 
simEcmgSLastCp, 
simEcmgSCwPrs, 
simEcmgSErrs 
} 

STATUS current 
DESCRIPTION 

" A collection of objects providing ECMG infomation. " 
::= {simGroups 2} 

simEmOrPdGroup OBJECT-GROUP 
OBJECTS { 
simEmOrPdIndex, 
simEmOrPdDataType, 
simEmOrPdClientId, 
simEmOrPdCommCapability, 
simEmOrPdErrs, 
simEmOrPdTargetCpsig , 
simEmOrPdCaMib, 
simEmOrPdLapIndex, 
simEmOrPdLapAdminState, 
simEmOrPdLapCommType, 
simEmOrPdLapMuxIpAddress, 
simEmOrPdLapMuxPort, 
simEmOrPdLapStatus, 
simEmOrPdChannelld, 
simEmOrPdCommType, 
s imEmOr PdC IpAddr e s s , 
simEmOrPdCPort, 
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simEmOrPdCErrs, 

simEmOrPdDatald, 

simEmOrPdSChannelld, 

simEmOrPdBwidth, 

simEmOrPdStreamId, 

simEmOrPdSErrs, 

simEmOrPdSBytes 

} 

STATUS current 

DESCRIPTION 

" A collection of objects providing EMMG/PDG infomation. 
: := { simGroups 3 } 

simEmOrPdLapGGroup OBJECT-GROUP 
OBJECTS { 

simEmOrPdLapGroup, 
simEmOrPdLapGAdminState, 
simEmOrPdLapGStatus 
} 

STATUS current 
DESCRIPTION 

" A collection of objects providing LAPG infomation. " 
::= {simGroups 4} 



simCpsigGroup OBJECT-GROUP 
OBJECTS { 
simCpsiglndex, 
simCpsigSuperCasId, 
simCpsigErrs, 
simCpsigChannels, 
simCpsigCpsiglpAddress, 
simCpsigCpsigPort, 
simCpsigCaMib, 
simCpsigChannelld, 
simCpsigPsiglpAddress, 
simCpsigPsigPort, 
simCpsigCErrs, 
simCpsigCTstrms, 
simCpsigCSstrms, 
simCpsigStreamTStreamId, 
simCpsigStreamNid , 
simCpsigStreamOnid , 
simCpsigStreamMaxCompTime 
simCpsigStreamTrigger Enable 
simCpsigStreamLast Trigger 
simCpsigStreamLastEventId 
SimCpsigStreamLast Service Id 
simCpsigStreamLastEsId , 
simCpsigStreamLastEcmPid 
simCpsigStreamErrs , 
simCpsigStreamBytes 



STATUS current 
DESCRIPTION 

" A collection of objects providing C(P)SIG) infomation. 
::= {simGroups 5} 



simPsigGroup OBJECT-GROUP 
OBJECTS { 

simPsiglndex, 
simPsigType, 
simPsigTrigger Support, 
simPsigNetworkId, 
simPsigONetworkId, 
simPsigTransStreamId, 
simPsigTS Services, 
simPsigConf igAdminState, 
simPsigConf igCustCasId, 
simPsigConf igMaxCompTime, 
SimPsigConf igServi eel d, 
simPsigConf igTrigger Enable, 
simPsigConf igEntryStatus, 
simPsigConf igCpsigType, 
simPsigConf igCADInsMode, 
simPsigEcmTrNetworkId, 
simPsigEcmTrONetworkId, 
simPsigEcmTrTransStreamId, 
simPsigEcmTr Service Id, 
simPsigEcmTrEsId, 
SimPsigEcmTr Type, 
simPsigEcmTrSuCasId, 
simPsigEcmTrEcmId, 
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simPsigEcmTrEcmPid, 

simPsigEcmTrAccessCriteria, 

simPsigEvntTrNetworkId, 

simPsigEvntTrONetworkId, 

simPsigEvntTrTransStreamId, 

simPsigEvntTr Service Id, 

simPsigEvntTr Event Id, 

SimPsigEvntTr St art Time, 

SimPsigEvntTr Duration, 

simPsigEvntTrPrivateData, 

simPsigFlowTr Index, 

simPsigFlowTrType, 

simPsigFlowTrSuCasId, 

simPsigFlowTrFlowId, 

simPsigFlowTrFlowPID, 

simPsigDesc Ins Index, 

simPsigDescInsAdminState, 

simPsigDescInsTr Index, 

simPsigDescInsTrType, 

simPsigDescInsLocationId, 

simPsigDescInsNetworkId, 

simPsigDescInsONetworkId, 

SimPsigDescInsTr ansStreamId, 

SimPsigDesc Ins Service Id, 

SimPsigDesc In sElmStreamId, 

simPsigDescInsBouquetId, 

simPsigDescInsEventId, 

simPsigDescInsNetworkldOther, 

simPsigDescInsONetworkId21oop, 

SimPsigDescInsTr ansStreamId20rO, 

simPsigDescInsDelayType, 

simPsigDescInsDelay, 

simPsigDescPrivDataSpf ier, 

simPsigDescInsEntryStatus, 

simPsigDescInsDesc Index, 

simPsigDescInsDescAdminState, 

simPsigDescInsDe script or, 

simPsigDescInsDescript or Status, 

simPsigDescInsDescEntry Status, 

simPsigTblProvIndex, 

simPsigTblProvTableld , 

simPsigTblNetworkId, 

simPsigTblONetworkId , 

simPsigTblTransStreamId , 

simPsigTblServiceld , 

simPsigTblBouquetId, 

simPsigTblEventId , 

simPsigTblNetworkldOther, 

simPsigTblONetworkId21oop, 

simPsigTblTransStreamId20rO, 

simPsigTblSegmentNr, 

simPsigTblProvPart, 

simPsigTblProvPartNumber, 

simPsigPIDProvFlowType, 

simPsigPIDProvSuCasId, 

simPsigPIDProvFlowId, 

simPsigPIDProvFlowPID 



STATUS current 
DESCRIPTION 

" A collection of objects providing (P)SIG) infomation. 
::= {simGroups 6} 



G.2 SEM MIB 



SEM-MIB DEFINITIONS: := BEGIN 



IMPORTS 

MODULE-IDENTITY, OBJECT-TYPE, 

Integer32, Unsigned32, BITS, IpAddress, TimeTicks, 

NOTIFICATION-TYPE FROM SNMPv2-SMI 

TEXTUAL-CONVENTION, RowStatus, 

DisplayString, TruthValue, DateAndTime FROM SNMPv2-TC 

MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 



FROM SNMPv2-C0NF; 



semMIB MODULE-IDENTITY 

LAST-UPDATED "9707021700Z 
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ORGANIZATION "DVB Simulcrypt Technical Group " 

CONTACT-INFO " " 

DESCRIPTION 

"The MIB module for defining DVB Simulcrypt Conditional 
Access System event information. " 
: := {1 3 6 1 4 1 2696 1 2} 

EntryName::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

" Entry name convention for tables . " 
SYNTAX OCTET STRING (SIZE (8)) 

EventType::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"An event type is indicated if the bit corresponding to its power of 
two is set, i.e. if the mask is 3 then communications and 
qualityOf Service event types are indicated. " 
SYNTAX BITS { 

communications (0) , 
qualityOf Service (1) , 
processingError (2) , 
equipmentAlarm (3) , 
environmental (4) , 
attributeValueChange (5) , 
stateChange (6) , 
timeDomainViolation (7) , 
securitySrvcOrMechnsmViolation (8) , 
relationshipChange (9) , 
operationalViolation (10) , 
integrityViolation (11) , 
physicalViolation (12) , 
thresholdCrossing (13) , 
thresholdClearing ( 14 ) 
} 

ProbableCause: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"Defined in ITU-T Recommendation X.733 [9] " 
SYNTAX BITS { 

simulcryptSpecif ic (0) , 

adapterError (1) , 

applicationSubsystemFailure (2) , 

bandwidthReduced (3) , 

callEstablishmentError (4) , 

communicationsProtocolError (5) , 

communicationsSubsystemFailure (6) , 

conf igurationOrCustomizationError (7) , 

congestion (8) , 

corruptData (9) , 

cpuCyclesLimitExceeded (10) , 

dataSetOrModemError (11) , 

degradedSignal (12) , 

dTEDCEInterfaceError (13) , 

enclosureDoorOpen (14) , 

equipmentMalfunction (15) , 

excessiveVibration (16) , 

fileError (17) , 

fireDetected(18) , 

floodDetected(19) , 

framingError (20) , 

heatOrVentOrCoolSystemProblem(21) , 

humidityUnacceptable (22) , 

inputOutputDeviceError (23) , 

inputDeviceError (24) , 

lANError (25) , 

leakDetected(26) , 

localNodeTransmissionError (27) , 

lossOfFrame (28) , 

lossOfSignal (29) , 

materialSupplyExhausted (30) , 

multiplexerProblem (31 ) , 

outOf Memory (32) , 

ouputDeviceError (33) , 

performanceDegraded (34) , 

powerProblem (35) , 

pressureUnacceptable (36) , 

processorProblem (37) , 

pumpFailure (38) , 

queueSizeExceeded (39) , 

receiveFailure (40) , 
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receiverFailure (41) , 
remoteNodeTransmissionError (42) , 
resourceAtOrNearingCapacity (43) , 
responseTimeExcessive (44) , 
retransmissionRateExcessive (45) , 
softwareError (46) , 

softProgramAbnormallyTerminated (47) , 
softwareProgramError (48) , 
storageCapacityProblem (49) , 
temperatureUnacceptable (50) , 
thresholdCrossed (51) , 
timingProblem (52) , 
toxicLeakDetected (53) , 
transmitFailure (54) , 
transmitterFailure (55) , 
underlyingResourceUnavailable (56) , 
versionMismatch (57) , 
authenticationFailure (58) , 
breachOfConfidentiality (59) , 
cableTamper (60) , 
delayedinf ormation (61) , 
denialOf Service (62) , 
duplicateinf ormation (63) , 
in format ionMis sing (64) , 
informationModif icationDetected (65) , 
informationOutOf Sequence (66) , 
intrusionDetection (67) , 
keyExpired (68) , 
nonRepudiationFailure (69) , 
outOfHoursActivity (70) , 
outOfService(71) , 
proceduralError (72) , 
unauthorizedAccessAttempt (73) , 
unexpectedinf ormation (74) , 
unspecif iedReason (75) 



PerceivedSeverity: := TEXTUAL-CONVENTION 

STATUS current 

DESCRIPTION 

"This convention defines six severity levels, which provide 
an indication of how it is perceived that the capability 
of the managed object has been affected. Those severity 
levels which represent service affecting conditions 
ordered from most severe to lease severe are Critical, 
Major, Minor, and Warning. 

Perceived Severity is defined in ITU-T Recommendation X.733 [9] . " 
SYNTAX BITS 

{ 

cleared (0) , 
indeterminate (1) , 
warning (2 ) , 
minor (3) , 
major (4) , 
critical (5) 
} 

Trendlndication: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"Indicates the trend of an event as defined in ITU-T Recommendation X.733 
SYNTAX BITS 

{ lessSevere (0) , 

noChange (1 ) , 
moreSevere (2) 
} 

BackedUpStatus: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"The backed up status as defined in ITU-T Recommendation X.733 [9] " 
SYNTAX BITS 
{ 

backedUp(O) , 

notBackedUp ( 1 ) 
} 

AdministrativeState: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 
"Administrative state as defined by ITU-T Recommendation X.734 [10] . " 
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SYNTAX BITS 

{ 

locked(O) , 
unlocked (1) , 

shuttingDown (2) 
} 

OperationalState: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"Operational state as defined by ITU-T Recommendation X.734 [10] . 
SYNTAX BITS 
{ 

enabled(O) , 

disabled(l) 
} 

AvailabilityStatus: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"Availability Status as defined by ITU-T Recommendation X.734 [IC 
SYNTAX BITS 

{ 
available (0) , 

inTest (1) , 
failed(2) , 
powerOff (3) , 
offLine (4) , 
offDuty (5) , 

dependency (6) , 
degraded (7) , 
notInstalled{8) , 
logFull (9) 



AlarmStatus: := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"Alarm Status as defined by ITU-T Recommendation X.734 [10]. " 
SYNTAX BITS 

{ 
underRepair (0) , 

critical (1) , 

major (2) , 

minor (3) , 

alarmOut standing (4 ) , 

cleared (5) 



EventSensitivity : := TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 
"Is the event caused by crossing of a threshold (edge) or by exceeding a threshold 
(level) . " 
SYNTAX BITS 

{ 
edgeSensitive (0) , 

levelSensitive (1) 



semMIBObjects OBJECT IDENTIFIER: : = {semMIB 1} 

semMIBConformance OBJECT IDENTIFIER: : = {semMIB 2} 
semMIBNotificationPrefix OBJECT IDENTIFIER: : = {semMIB 3} 

semEvent OBJECT IDENTIFIER: : = {semMIBObjects 1} 

semEfd OBJECT IDENTIFIER: := {semMIBObjects 2} 



Event Section 



semEventTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SemEventEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A table of management event information. " 
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: := { semEvent 1 } 

semEventEntry OBJECT-TYPE 

SYNTAX SemEventEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Information about a single management event. 
INDEX {semEventName} 
: := {semEventTable 1} 



SemEventEntry: := SEQUENCE { 
semEventName 
semEvent AdminSt ate 
semEvent Alarms tat us 
semEvent Type 
semEvent Text 
semEvent ChangedObject Id 
semEvent ToSt at eChange 
semEvent RisingThreshold 
semEvent FallingThresho Id 
semEvent ProbableCause 
semEventPerceivedSeverity 
semEvent Trendlndi cat ion 
semEvent BackedUpS tat us 
semEvent BackUpObject 
semEvent SpecificProblems 
semEvent Frequency 
semEvent Sensitivity 
semEvent St at us 

} 



EntryName, 
AdministrativeState, 
AlarmStatus, 

EventType, 
DisplayString, 
OBJECT IDENTIFIER, 
Unsigned32 , 
Integer32, 
Integer32, 
ProbableCause, 
PerceivedSeverity , 
Trendlndi cat ion, 
BackedUpStatus, 

OBJECT IDENTIFIER, 
OBJECT IDENTIFIER, 
Integer32, 
Event Sensitivity, 
RowStatus 



semEventName OBJECT-TYPE 
SYNTAX EntryName 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The unique name of the target event. " 
::= {semEventEntry 1} 

semEventAdminState OBJECT-TYPE 

SYNTAX AdministrativeState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The Administrative State of the event entry. 
::= {semEventEntry 2} 

semEventAlarmStatus OBJECT-TYPE 
SYNTAX AlarmStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The Alarm Status of an event. " 
::= {semEventEntry 3} 



semEventType OBJECT-TYPE 
SYNTAX EventType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Indicates the type of the event . 
::= {semEventEntry 4} 



semEventText OBJECT-TYPE 

SYNTAX DisplayString 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"A description of the event's function and use. 
DEFVAL { ' 'H} 
::= {semEventEntry 5} 



semEventChangedObjectId OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 

MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 
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"The object identifier of the MIB object to check to see 
if the event should fire. 

This may be wildcarded by truncating all or part of the 
instance portion, in which case the condition is obtained 
as if with a GetNext function, checking multiple values 
if they exist. " 
{ semEventEntry 6} 



semEventToStateChange OBJECT-TYPE 
SYNTAX Unsigned32 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" If semEvent ChangedOb jectid is a state/status/variable, 
this variable identifies the state that causes the 
event to be generated. " 
::= {semEventEntry 7} 

semEvent RisingThreshold OBJECT-TYPE 
SYNTAX Integer32 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" A threshold value to check against if semEventType is 
'threshold' . In this case if the value of the object at 
semEventValuelD is greater than or equal to this threshold 
and the value at the last sampling interval was less than 
this threshold, one semEventRisingEvent is triggered. 
If semEventType is not 'threshold', this object is not 
instantiated. " 
DEFVAL { } 
::= {semEventEntry 8} 

semEventFallingThreshold OBJECT-TYPE 
SYNTAX Integer32 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" A threshold value to check against if semEventType is 
'threshold' . In this case if the value of the object at 
semEventValuelD is less than or equal to this threshold 
and the value at the last sampling interval was greater than 
this threshold, one semEventFallingEvent is triggered. 
If semEventType is not 'threshold', this object is not 
instantiated. " 
DEFVAL { } 
::= {semEventEntry 9} 

semEvent ProbableCause OBJECT-TYPE 
SYNTAX ProbableCause 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This variable defines further probable cause for 
the last event of this type. " 
::= {semEventEntry 10} 

semEventPerceivedSeverity OBJECT-TYPE 
SYNTAX PerceivedSeverity 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This parameter defines the pereceived severity of the 
last event of this type. " 
::= {semEventEntry 11} 

semEvent Trendlndi cat ion OBJECT-TYPE 
SYNTAX Trendlndication 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Indicates the trend of the last event of this type. " 
::= {semEventEntry 12} 

semEventBackedUpStatus OBJECT-TYPE 
SYNTAX BackedUpStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The backed up status. " 
::= {semEventEntry 13} 
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semEventBackUpObject OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" If the backed up status is backedUp then this variable 
ontains the object identifier of the object containing 
back up object. " 
::= { semEventEntry 14} 

semEventSpecificProblems OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" This variable identifies the object responsible for the event. " 
::= {semEventEntry 15} 

semEventFrequency OBJECT-TYPE 

SYNTAX Integer32 (1.. 65535) 
UNITS "seconds " 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The number of seconds to wait between event condition 
checks. To encourage consistency in sampling, the 
interval is measured from the beginning of one check to 
the beginning of the next. " 
DEFVAL {600} 
::= {semEventEntry 16} 

semEventSensitivity OBJECT-TYPE 
SYNTAX EventSensitivity 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The event sensitivity which identifies whether the event is level or edge 
sensitive. " 
::= {semEventEntry 17} 

semEventStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The control that allows creation/deletion of entries. " 
::= {semEventEntry 18} 



— Event Forwarding Discriminator (EFD) Status Section 



semEfdTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SemEfdEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A table of management EFDs . " 
: := {semEfd 1 } 

SemEfdEntry OBJECT-TYPE 

SYNTAX SemEfdEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Information about a single EFD. " 
INDEX {semEfdName , semEf dTarget } 
: := {semEfdTable 1} 

SemEfdEntry : := SEQUENCE { 

semEfdName EntryName, 

semEfdAdminState AdministrativeState, 

semEfdOperState OperationalState, 

semEfdAvailStatus Availability Status, 

semEfdStartTime DateAndTime, 

semEfdStopTime DateAndTime, 
semEfdDailyStartTime TimeTicks, 
semEfdDailyStopTime TimeTicks, 

semEfdWeeklyMask OCTET STRING, 
semEfdTypes EventType, 
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semEfdCause ProbableCause, 

semEfdSeverity PerceivedSeverity, 
semEfdSpecificProblems OBJECT IDENTIFIER, 
semEfdTrendlndication Trendlndication, 
semEfdChangedObjectId OBJECT IDENTIFIER, 
semEfdToStateChange Unsigned32, 

semEfdNotification OBJECT IDENTIFIER, 

semEfdOr TruthValue, 

semEfdTarget IpAddress, 

semEfdText DisplayString, 

semEfdStatus RowStatus 



} 



semEfdName OBJECT-TYPE 

SYNTAX EntryName 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The unique name of the EFD . " 
: := {semEfdEntry 1} 

semEfdAdminState OBJECT-TYPE 

SYNTAX AdministrativeState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The current Adminsitrative state of the EFD. " 
: := {semEfdEntry 2} 

semEfdOperState OBJECT-TYPE 
SYNTAX OperationalState 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The current Operational state of the EFD. " 
: := {semEfdEntry 3} 

semEfdAvailStatus OBJECT-TYPE 
SYNTAX AvailabilityStatus 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" This object controls the Availability status of the EFD 
which reflects the scheduling. " 
: := {semEfdEntry 4} 

semEfdStartTime OBJECT-TYPE 
SYNTAX DateAndTime 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the date and time at which an unlocked and 
enabled EFD starts functioning, i.e. changes its 
availability status from off Duty to available. " 
::= {semEfdEntry 5} 

semEfdStopTime OBJECT-TYPE 
SYNTAX DateAndTime 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the date and time at which an unlocked and 
enabled EFD stops functioning, i.e. changes its 
availability status from available to off Duty. " 
::= {semEfdEntry 6} 

semEfdDailyStartTime OBJECT-TYPE 
SYNTAX TimeTicks 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the daily start time at which an unlocked and 
enabled EFD starts functioning, i.e. changes its 
availability status from off Duty to available. " 
: := {semEfdEntry 7} 

semEfdDailyStopTime OBJECT-TYPE 
SYNTAX TimeTicks 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the daily stop time at which an unlocked and 
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enabled EFD stops functioning, i.e. changes its 
availability status from available to off Duty. " 
: := {semEfdEntry 8} 

semEfdWeeklyMask OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (1)) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the weekly schedule at which an unlocked and 
enabled EFD may start functioning, i.e. changes its 
availability status from available to off Duty. A day is 
scheduled if the cooresponding power of 2, i.e. 2**3 for 
Wednesday is in the mask. " 
: := {semEfdEntry 9} 

semEfdTypes OBJECT-TYPE 

SYNTAX EventType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The event types that this EFD may generate notifications for. " 
: := {semEfdEntry 10} 

semEfdCause OBJECT-TYPE 

SYNTAX ProbableCause 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Any event with a different probable cause is ignored. " 
::= {semEfdEntry 11} 

semEfdSeverity OBJECT-TYPE 

SYNTAX PerceivedSeverity 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Any event with severity equal to or less the discriminated level 
is ignored. " 

: := {semEfdEntry 12} 

semEfdSpecificProblems OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Any event not generated by the identified object is ignored. " 
: := {semEfdEntry 13} 

semEfdTrendlndication OBJECT-TYPE 
SYNTAX Trendlndication 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Any events with a trend less or equal to specified value are 
ignored. " 
: := {semEfdEntry 14} 

semEfdChangedObjectId OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Any events not caused by a change of the value of this object 
are ignored. " 
: := {semEfdEntry 15} 

semEfdToStateChange OBJECT-TYPE 
SYNTAX Unsigned32 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Any state changes to a different state than the one indicated are 
ignored. " 
: := {semEfdEntry 16} 

semEfdNotification OBJECT-TYPE 

SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The object identifier from the NOTIFICATION-TYPE for the 
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notification. " 

: := {semEfdEntry 17} 

semEfdOr OBJECT-TYPE 

SYNTAX TruthValue 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Indicates whether if this EFD matches the event, the matching 
process shall be continued with the next EFD. " 
: := {semEfdEntry 18} 

semEfdTarget OBJECT-TYPE 
SYNTAX IpAddress 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Notifications Targets. A value of 
indicates the local system. " 
: := {semEfdEntry 19} 

semEfdText OBJECT-TYPE 

SYNTAX DisplayString 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"A description of the EFD ' s function and use. " 
: := {semEfdEntry 20} 



semEfdStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The control that allows creation/deletion of entries. 
: := {semEfdEntry 21} 



— Notifications 



semMIBNotifications OBJECT IDENTIFIER: : = { semMIBNotif icationPref ix 0} 



semEventAlarm NOTIFICATION-TYPE 
OBJECTS 

{ semEventName, 
semEventType , 
semEventProbableCause, 
semEvent Specif icProblems, 
semEventPerceivedSeverity, 
semEvent Trendlndi cat ion, 
semEvent Text 
} 
STATUS current 
DESCRIPTION 

" Alarm notification. " 
: := {semMIBNotifications 1} 



semEvent St ateChange NOTIFICATION-TYPE 
OBJECTS 

{ semEventName, 

semEvent ToSt ateChange, 
semEvent ChangedObject Id 
} 
STATUS current 
DESCRIPTION 

" State change notification. " 
: := {semMIBNotifications 2} 

semEventObjectValueChange NOTIFICATION-TYPE 
OBJECTS 

{ SemEventName, 

semEvent ChangedObject Id 
} 
STATUS current 
DESCRIPTION 

" Object value change. " 
: := {semMIBNotifications 3} 
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— Conformance Information 



semCompliances OBJECT IDENTIFIER: : = { semMIBConf ormance 1} 
semGroups OBJECT IDENTIFIER: : = { semMIBConf ormance 2} 

semECMGCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent ECMGs . A hosting entity must also support either 
threshold, state change, or value change events. " 
MODULE — this module 

MANDATORY-GROUPS { semMandatoryNotif ications } 
GROUP semThresholdEventGroup 
DESCRIPTION 

" This group is required if thresold events are supported. " 
GROUP semThresholdEventOptGroup 
DESCRIPTION 

" This group is optional if thresold events are supported. " 
GROUP semThresholdEfdGroup 
DESCRIPTION 

" This group is required if threshold events are supported. " 
GROUP semThresholdEfdOptGroup 
DESCRIPTION 

" This group is optional if threshold events are supported. " 
GROUP semStateChangeEventGroup 
DESCRIPTION 

" This Group is required if stateChange events are supported. " 
GROUP semSt at eChangeEvent Opt Group 
DESCRIPTION 

" This Group is optional if stateChange events are supported. " 
GROUP semStateChangeEfdGroup 
DESCRIPTION 

" This Group is required if stateChange events are supported. " 
GROUP semStateChangeEfdOptGroup 
DESCRIPTION 

" This Group is optional if stateChange events are supported. " 
GROUP semValueChangeEventGroup 
DESCRIPTION 

" This Group is required valueChange events are supported. " 
GROUP semValueChangeEvent Opt Group 
DESCRIPTION 

" This Group is optional valueChange events are supported. " 
GROUP semValueChangeEfdGroup 
DESCRIPTION 

" This Group is required valueChange events are supported. " 
GROUP semValueChangeEfdOptGroup 
DESCRIPTION 

" This Group is optional valueChange events are supported. " 
GROUP semOptionalNotif ications 
DESCRIPTION 

" This Group is required if state change or value change notifications 
are supported. " 
::= {semCompliances 1} 

semEmOrPdCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent EMMG/PDGs. A hosting entity must also support either 
threshold, state change, or value change events. " 
MODULE — this module 

MANDATORY-GROUPS { semMandatoryNotif ications } 
GROUP semThresholdEventGroup 
DESCRIPTION 

" This group is required if thresold events are supported. " 
GROUP SemThresholdEventOptGroup 
DESCRIPTION 

" This group is optional if thresold events are supported. " 
GROUP semThresholdEfdGroup 
DESCRIPTION 

" This group is required if threshold events are supported. " 
GROUP SemThresholdEfdOptGroup 
DESCRIPTION 

" This group is optional if threshold events are supported. " 
GROUP SemStateChangeEventGroup 
DESCRIPTION 

" This Group is required if stateChange events are supported. " 
GROUP semS tat eChangeEvent Opt Group 
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DESCRIPTION 

" This Group is optional if stateChange events are supported. " 
GROUP semStateChangeEfdGroup 
DESCRIPTION 

" This Group is required if stateChange events are supported. " 
GROUP semStateChangeEfdOptGroup 
DESCRIPTION 

" This Group is optional if stateChange events are supported. " 
GROUP semValueChangeEventGroup 
DESCRIPTION 

" This Group is required valueChange events are supported. " 
GROUP semValueChangeEvent Opt Group 
DESCRIPTION 

" This Group is optional valueChange events are supported. " 
GROUP semValueChangeEfdGroup 
DESCRIPTION 

" This Group is required valueChange events are supported. " 
GROUP semValueChangeEfdOptGroup 
DESCRIPTION 

" This Group is optional valueChange events are supported. " 
GROUP semOptionalNotif ications 
DESCRIPTION 

" This Group is required if state change or value change notifications 
are supported. " 
::= { semCompliances 2} 

semCpsigCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent CPSIGs. A hosting entity must also support either 
threshold, state change, or value change events. " 
MODULE — this module 

MANDATORY-GROUPS { semMandatoryNotif ications } 
GROUP semThresholdEventGroup 
DESCRIPTION 

" This group is required if thresold events are supported. " 
GROUP semThresholdEventOptGroup 
DESCRIPTION 

" This group is optional if thresold events are supported. " 
GROUP semThresholdEfdGroup 
DESCRIPTION 

" This group is required if threshold events are supported. " 
GROUP semThresholdEfdOptGroup 
DESCRIPTION 

" This group is optional if threshold events are supported. " 
GROUP semStateChangeEventGroup 
DESCRIPTION 

" This Group is required if stateChange events are supported. " 
GROUP semSt at eChangeEvent Opt Group 
DESCRIPTION 

" This Group is optional if stateChange events are supported. " 
GROUP SemStateChangeEfdGroup 
DESCRIPTION 

" This Group is required if stateChange events are supported. " 
GROUP SemStateChangeEfdOptGroup 
DESCRIPTION 

" This Group is optional if stateChange events are supported. " 
GROUP SemValueChangeEventGroup 
DESCRIPTION 

" This Group is required valueChange events are supported. " 
GROUP SemValueChangeEvent Opt Group 
DESCRIPTION 

" This Group is optional valueChange events are supported. " 
GROUP SemValueChangeEfdGroup 
DESCRIPTION 

" This Group is required valueChange events are supported. " 
GROUP SemValueChangeEfdOptGroup 
DESCRIPTION 

" This Group is optional valueChange events are supported. " 
GROUP semOptionalNotif ications 
DESCRIPTION 

" This Group is required if state change or value change notifications 
are supported. " 
::= {semCompliances 3} 

semCsigCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent CSIGs. A hosting entity must also support either 
threshold, state change, or value change events. " 
MODULE — this module 
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MANDATORY-GROUPS { semMandatoryNotif ications } 

GROUP semThresholdEventGroup 

DESCRIPTION 

" This group is required if thresold events are supported. " 
GROUP semThresholdEventOptGroup 
DESCRIPTION 

" This group is optional if thresold events are supported. " 
GROUP semThresholdEfdGroup 
DESCRIPTION 

" This group is required if threshold events are supported. " 
GROUP semThresholdEfdOptGroup 
DESCRIPTION 

" This group is optional if threshold events are supported. " 
GROUP semStateChangeEventGroup 
DESCRIPTION 

" This Group is required if stateChange events are supported. " 
GROUP semSt at eChangeEvent Opt Group 
DESCRIPTION 

" This Group is optional if stateChange events are supported. " 
GROUP semStateChangeEfdGroup 
DESCRIPTION 

" This Group is required if stateChange events are supported. " 
GROUP semStateChangeEfdOptGroup 
DESCRIPTION 

" This Group is optional if stateChange events are supported. " 
GROUP semValueChangeEventGroup 
DESCRIPTION 

" This Group is required valueChange events are supported. " 
GROUP semValueChangeEvent Opt Group 
DESCRIPTION 

" This Group is optional valueChange events are supported. " 
GROUP semValueChangeEfdGroup 
DESCRIPTION 

" This Group is required valueChange events are supported. " 
GROUP semValueChangeEfdOptGroup 
DESCRIPTION 

" This Group is optional valueChange events are supported. " 
GROUP semOptionalNotif ications 
DESCRIPTION 

" This Group is required if state change or value change notifications 
are supported. " 
::= { semCompliances 4} 

semMandatoryNotif ications NOTIFICATION-GROUP 
NOTIFICATIONS { 

semEvent Alarm 
1 

STATUS current 
DESCRIPTION 

" A collection of objects defining mandatory notifications. " 
: := { semGroups 1 } 

semOptionalNotif ications NOTIFICATION-GROUP 
NOTIFICATIONS { 

semEvent StateChange, 
semEvent Ob ject ValueChange 
} 

STATUS current 
DESCRIPTION 

" A collection of objects defining optional notifications. " 
::= {semGroups 2} 

SemThresholdEventGroup OBJECT-GROUP 
OBJECTS { 

semEventName , 

semEvent AdminSt ate, 

semEvent Type, 

semEventText , 

semEvent ChangedOb ject Id, 

semEvent RisingThresho Id, 

semEvent Fall ingThresho Id, 

semEvent ProbableCause, 

semEventPerceivedSeverity, 

semEvent Trendlndi cat ion, 

semEvent Frequency, 

semEvent St at us 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying threshold events. " 
: := { semGroups 3 } 

SemThresholdEventOptGroup OBJECT-GROUP 
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OBJECTS { 

semEventAlarmStatus, 

semEventBackedUpStatus, 

semEventBackUpOb ject, 

semEventSpecif icProblems, 

semE vent Sensitivity 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying threshold events. 
: := { semGroups 4 } 

semStateChangeEventGroup OBJECT-GROUP 
OBJECTS { 

semEventName , 

semEventAdminState, 

semEventType, 

semEventText , 

semEventChangedOb jectid, 

semEventToStateChange, 

semEvent Frequency, 

semEventStatus 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying state change events. " 
::= {semGroups 5} 



semStateChangeEventOptGroup OBJECT-GROUP 
OBJECTS { 

semEvent AlarmStatus, 

semEvent ProbableCause, 

semEventPerceivedSeverity, 

semEvent Trendlndi cat ion, 

SemEventBackedUpStatus, 

SemEventBackUpOb ject, 

semEventSpecif icProblems, 

semEvent Sensitivity 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying state change events. 
: := { semGroups 6 } 

semValueChangeEvent Group OBJECT-GROUP 
OBJECTS { 

semEventName , 

SemEventAdminState, 

semEventType , 

semEventText , 

SemEventChangedOb jectid, 

semEvent Frequency, 

semEventStatus 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying value change events. " 
: := { semGroups 7 } 



SemValueChangeEvent Opt Group OBJECT-GROUP 
OBJECTS { 

semEvent AlarmStatus, 

semEvent ProbableCause, 

semEventPerceivedSeverity, 

semEvent Trendlndi cat ion, 

SemEventBackedUpStatus, 

SemEventBackUpOb ject, 

semEventSpecif icProblems, 

semEvent Sensitivity 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying value change events. 
: := { semGroups 8 } 

semThresholdEfdGroup OBJECT-GROUP 
OBJECTS { 

semEf dName, 
semEf dAdminState, 
semEfdOperState, 
semEf dAvailStatus, 
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semEfdTypes, 

semEfdCause , 

semEfdSeverity, 

semEfdTrendlndication , 

semEfdChangedOb jectid, 
semEfdNotif ication, 

semEfdOr, 

semEfdTarget, 

semEfdText, 

semEf dStatus 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying threshold EFDs. " 
: := { semGroups 9 } 

semThresholdEfdOptGroup OBJECT-GROUP 
OBJECTS { 

semEfdS tart Time, 

semEfdStopTime, 

semEfdDailyStartTime, 

semEfdDailyStopTime, 

semEfdWeeklyMask, 

semEf dSpecif icProblems 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying threshold EFDs. " 
::= {semGroups 10} 

semStateChangeEfdGroup OBJECT-GROUP 
OBJECTS { 

semEfdName, 
semEfdAdminState, 
semEfdOperState, 
semEf dAvailStatus, 
semEfdTypes, 
semEfdToStateChange, 

semEfdNotif ication, 
semEfdOr, 
semEfdTarget, 
semEfdText, 
semEfdStatus 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying state change EFDs. " 
::= {semGroups 11} 

semStateChangeEfdOptGroup OBJECT-GROUP 
OBJECTS { 

semEfdS tart Time, 

SemEfdStopTime, 

SemEfdDailyStartTime, 

SemEfdDailyStopTime, 

semEfdCause , 

semEfdSeverity, 

semEfdTrendlndication , 

SemEfdChangedOb jectid, 

SemEfdWeeklyMask, 

semEfdSpecif icProblems 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying state change EFDs. 
::= {semGroups 12} 

semValueChangeEfdGroup OBJECT-GROUP 
OBJECTS { 

semEfdName, 

SemEfdAdminState, 

SemEfdOperState, 

semEf dAvailStatus, 

semEfdTypes, 

SemEfdChangedOb jectid, 
semEfdNotif ication, 

semEfdOr, 

semEfdTarget, 

semEfdText, 

semEfdStatus 
} 

STATUS current 
DESCRIPTION 
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" A collection of objects specifying value change EFDs. " 
::= {semGroups 13} 

semValueChangeEfdOptGroup OBJECT-GROUP 
OBJECTS { 

semEfdS tart Time, 

semEfdStopTime, 

semEfdDailyStartTime, 

semEfdDailyStopTime, 

semEfdCause , 

semEfdSeverity, 

semEfdTrendlndication , 

semEfdWeeklyMask, 

semEf dSpecif icProblems 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying value change EFDs. 
::= {semGroups 14} 



G.3 SLM MIB 

SLM-MIB DEFINITIONS: := BEGIN 

IMPORTS 

MODULE-IDENTITY, OBJECT-TYPE, 

Unsigned32, BITS, TimeTicks FROM SNMPv2-SMI 

RowStatus, DisplayString, DateAndTlme FROM SNMPv2-TC 

MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-C0NF 

EventType, ProbableCause, PerceivedSeverity, Trendlndication, 

AdministrativeState, Operational St ate, 

AvailabilityStatus, EntryName FROM SEM-MIB; 

slmMIB MODULE-IDENTITY 

LAST-UPDATED "9708071700Z " 

ORGANIZATION "DVB Simulcrypt Technical Group " 

CONTACT-INFO " " 

DESCRIPTION 

"The MIB module for defining DVB Simulcrypt Conditional 
Access System logs information. " 
: := {1 3 6 1 4 1 2696 1 3} 

slmMIBObjects OBJECT IDENTIFIER: : = {slmMIB 1} 
slmMIBConformance OBJECT IDENTIFIER: : = {slmMIB 2} 

slmLogControl OBJECT IDENTIFIER: : = {slmMIBObjects 1} 

slmLogs OBJECT IDENTIFIER: : = {slmMIBObjects 2} 

— Log Control Group 

slmLogDefinitionTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SlmLogDef initionEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A list of Log Table Entry Definitions. Identifies log table 
and the types of events to be logged into that table. " 
REFERENCE " — " 
::= {SlmLogControl 1} 

SlmLogDef initionEntry OBJECT-TYPE 

SYNTAX SlmLogDefinitionEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry (conceptual row) in the Log Definition Table. " 
REFERENCE " — " 
INDEX { SlmLogDef initionName } 
::= {slmLogDefinitionTable 1} 

SlmLogDefinitionEntry: := SEQUENCE 
{ 

SlmLogDef initionName EntryName, 
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slmLogDefinitionld OBJECT IDENTIFIER, 

slmLogDef initionAdminState AdministrativeState, 
slmLogDef initionOperState Operational St ate, 
SlmLogDef initionAvailStatus Availability Status, 
slmLogDefinitionFullAction BITS, 
slmLogDefinitionMaxLogSize INTEGER, 
SlmLogDef initionCur rent Logs ize INTEGER, 
slmLogDefinitionNumber Of Records INTEGER 
} 

slmLogDefinitionName OBJECT-TYPE 
SYNTAX EntryName 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The variable used for identifying log Definition table entries. 
REFERENCE " — " 
::= { slmLogDef initionEntry 1} 

SlmLogDefinitionld OBJECT-TYPE 

SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The variable used for identifying log tables. " 
REFERENCE " — " 
::= { slmLogDef initionEntry 2} 

SlmLogDef initionAdminState OBJECT-TYPE 
SYNTAX AdministrativeState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The current Adminsitrative state of the LOG as defined in 
ISO/IEC 10164-2 [8] 
::= { slmLogDef initionEntry 3} 

SlmLogDef initionOperState OBJECT-TYPE 
SYNTAX OperationalState 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" The current Operational state of the LOG as defined in 
ISO/IEC 10164-2 [8] 
::= { SlmLogDef initionEntry 4} 

SlmLogDef InitionAvailStatus OBJECT-TYPE 
SYNTAX AvailabilityStatus 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" This object Definitions the Availability status of the LOG 
as defined in ISO/IEC 10164-2 [8] and state-machine " 
::= { SlmLogDef initionEntry 5} 

SlmLogDefinitionFullAction OBJECT-TYPE 
SYNTAX BITS 
{ 

wrap (0) , 
halt (1) 
} 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This object Definitions the action to be taken when the maximum 
size of the log has been reached. " 
::= { slmLogDef initionEntry 6} 

SlmLogDefinitionMaxLogSize OBJECT-TYPE 

SYNTAX INTEGER ( 1 . . 42 94 9 672 95 ) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" This object specifies the maximum size of a log in number 

of octets. A size of 2**32 - 1 specifies that there is no limit. 
::= { slmLogDef initionEntry 7} 

SlmLogDef initionCur rent Logs ize OBJECT-TYPE 
SYNTAX INTEGER ( 1 . . 42 94 9 672 95 ) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" This object specifies the current size of a log in number 
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of octets. " 
::= { slmLogDef initionEntry 8} 

slmLogDefinitionNumber Of Records OBJECT-TYPE 
SYNTAX INTEGER ( 1 . . 42 94 9 672 95 ) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" This object specifies the number of records in the log. " 
REFERENCE "ITU-T Recommendation X.735 [11] " 
::= { SlmLogDef initionEntry 9} 

slmLogControlTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SlmLogControlEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A list of Log Table Filter Definitions. Since 
multiple types of events can be logged into the same table, 
multiple entries in the log table could be defining the same 
log table. " 
REFERENCE " — " 
::= { slmLogControl 2} 

SlmLogControlEntry OBJECT-TYPE 

SYNTAX SlmLogControlEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry (conceptual row) in the Log Control Table. " 
REFERENCE " — " 
INDEX { slmLogDef initionName, slmLogControlName } 
::= (slmLogControlTable 1} 

SlmLogControlEntry: := SEQUENCE 
{ 

SlmLogControlName EntryName, 

SlmLogControl St art Time DateAndTime, 

slmLogControlStopTime DateAndTime, 

slmLogControlDailyStartTime TimeTicks, 

slmLogControlDailyStopTime TimeTicks, 

slmLogControlWeeklyMask OCTET STRING, 

slmLogControlTypes EventType, 

slmLogControlCause ProbableCause, 

slmLogControlSeverity PerceivedSeverity, 

slmLogControlSpecificProblems OBJECT IDENTIFIER, 

slmLogControlToStateChange Unsigned32 , 

slmLogControlTrendlndication Trendlndication, 

slmLogControlChangedObjectld OBJECT IDENTIFIER, 

slmLogControlStatus RowStatus 
} 
SlmLogControlName OBJECT-TYPE 

SYNTAX EntryName 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

" The variable used for identifying log control table entries. " 

REFERENCE " — " 
::= {SlmLogControlEntry 1} 

slmLogControlSt art Time OBJECT-TYPE 
SYNTAX DateAndTime 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the date and time at which an unlocked and 
enabled log control entry starts functioning, i.e. changes its 
availability status from off Duty to available. " 
::= {SlmLogControlEntry 2} 

SlmLogControlStopTime OBJECT-TYPE 
SYNTAX DateAndTime 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the date and time at which an unlocked and 
enabled log control stops functioning, i.e. changes its 
availability status from available to off Duty. " 
::= {SlmLogControlEntry 3} 

SlmLogControlDailyStartTime OBJECT-TYPE 
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SYNTAX TimeTicks 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the daily start time at which an unlocked and 
enabled log control entry starts functioning, i.e. changes its 
availability status from off Duty to available. " 
::= { slmLogControlEntry 4} 

slmLogControlDailyStopTime OBJECT-TYPE 
SYNTAX TimeTicks 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the daily start time at which an unlocked and 
enabled log control entry stops functioning, i.e. changes its 
availability status from available to off Duty. " 
::= {slmLogControlEntry 5} 

slmLogControlWeeklyMask OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (1)) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the weekly schedule at which an unlocked and 
enabled log control entry may start functioning, i.e. changes its 
availability status from available to off Duty. A day is 
scheduled if the cooresponding power of 2, i.e. 2**3 for 
Wednesday is in the mask. " 
::= {slmLogControlEntry 6} 

slmLogControlTypes OBJECT-TYPE 
SYNTAX EventType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" This variable defines the type of events being logged. " 
::= {slmLogControlEntry 7} 

slmLogControlCause OBJECT-TYPE 

SYNTAX ProbableCause 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Any event with a different probable cause is ignored. " 
::= {slmLogControlEntry 8} 

slmLogControlSeverity OBJECT-TYPE 

SYNTAX PerceivedSeverity 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Any event with severity equal to or less the discriminated level 
is ignored. " 

::= {slmLogControlEntry 9} 

slmLogControlSpecificProblems OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Any event not generated by the identified object is ignored. " 
::= {slmLogControlEntry 10} 

slmLogControlToStateChange OBJECT-TYPE 
SYNTAX Unsigned32 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
" Any state changes to a different state than the one indicated are 
ignored. " 
::= {slmLogControlEntry 11} 

slmLogControlTrendlndication OBJECT-TYPE 
SYNTAX Trendlndication 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

" Any events with a trend less or equal to specified value are 
ignored. " 
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::= { slmLogControlEntry 12} 

slmLogControlChangedObjectld OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"Any events not caused by a change of the value of this object 
are ignored. " 
::= {slmLogControlEntry 13} 

slmLogControlStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The control that allows creation/deletion of entries. 
Once made active an entry may not be modified except to. " 
::= {slmLogControlEntry 14} 

— Alarm Log Group 



slmAlarmLogTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SlmAlarmLogEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A table of logged alarm events. " 
: := { slmLogs 1 } 

SlmAlarmLogEntry OBJECT-TYPE 

SYNTAX SlmAlarmLogEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A single alarm log. " 
INDEX {slmAlarmLogTime} 
::= {slmAlarmLogTable 1} 

SlmAlarmLogEntry : := SEQUENCE { 

slmAlarmLogName EntryName, 
SlmAlarmLogTime TimeTicks, 
slmAlarmLogText DisplayString, 
slmAlarmLogType EventType, 
slmAlarmLogCause ProbableCause, 
slmAlarmLogSeverity PerceivedSeverity, 
slmAlarmLogSpecificProblems OBJECT IDENTIFIER, 
slmAlarmLogTrendlndication Trendlndication, 
slmAlarmLogChangedObjectld OBJECT IDENTIFIER 



SlmAlarmLogName OBJECT-TYPE 
SYNTAX EntryName 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The name of the logged event. " 
::= {SlmAlarmLogEntry 1} 

SlmAlarmLogTime OBJECT-TYPE 
SYNTAX TimeTicJcs 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The name of the logged event. " 
::= {SlmAlarmLogEntry 2} 

SlmAlarmLogText OBJECT-TYPE 

SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"A description of the event's function and use. 
DEFVAL { ' 'H} 
::= {SlmAlarmLogEntry 3} 

SlmAlarmLogType OBJECT-TYPE 

SYNTAX EventType 
MAX-ACCESS read-only 
STATUS current 
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DESCRIPTION 
" Indicates the type of the event. " 
::= { slmAlarmLogEntry 4} 

slmAlarmLogCause OBJECT-TYPE 
SYNTAX ProbableCause 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"This variable defines further probable cause for 
the event . " 
::= {slmAlarmLogEntry 5} 

slmAlarmLogSeverity OBJECT-TYPE 

SYNTAX PerceivedSeverity 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This parameter defines the Perceived severity of the 
event . " 
::= {slmAlarmLogEntry 6} 

slmAlarmLogSpecificProblems OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" This variable identifies the object responsible for the event. 
::= {slmAlarmLogEntry 7} 

slmAlarmLogTrendlndication OBJECT-TYPE 
SYNTAX Trendlndication 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Indicates the trend of the event. " 
::= {slmAlarmLogEntry 8} 

slmAlarmLogChangedObjectld OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" The object identifier of the object which changed value. " 
::= {slmAlarmLogEntry 9} 



— State Logs Group 



slmStateChangeLogTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SlmStateChangeLogEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A table of logged stateChange events. " 
: : = { slmLogs 2 } 

SlmStateChangeLogEntry OBJECT-TYPE 

SYNTAX SlmStateChangeLogEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A single stateChange log. " 
INDEX {slmStateChangeLogTime} 
::= {slmStateChangeLogTable 1} 

SlmStateChangeLogEntry: := SEQUENCE { 

slmStateChangeLogName EntryName, 

SlmStateChangeLogTime TimeTicks, 

slmStateChangeLogText Display St ring, 

slmStateChangeLogToStateChange Unsigned32 , 

slmStateChangeLogChangedObjectld OBJECT IDENTIFIER 

} 

SlmStateChangeLogName OBJECT-TYPE 
SYNTAX EntryName 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The name of the logged event. " 
::= {SlmStateChangeLogEntry 1} 
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slmStateChangeLogTime OBJECT-TYPE 
SYNTAX TimeTicks 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The name of the logged event . " 
::= { slmStateChangeLogEntry 2} 

slmStateChangeLogText OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"A description of the event's function and use. " 
DEFVAL { ' 'H} 
::= {slmStateChangeLogEntry 3} 

slmStateChangeLogToStateChange OBJECT-TYPE 
SYNTAX Unsigned32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"If ChangedOb jectid is a state/status/variable, 
this variable identifies the state that caused the 
event to be generated. " 
::= {slmStateChangeLogEntry 4} 

slmStateChangeLogChangedOb jectid OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The object identifier of the MIB object that caused the event. 
::= {slmStateChangeLogEntry 5} 

— Object Value Change Logs Group 

slmValueChangeLogTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SlmValueChangeLogEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A table of logged valuechange events. " 
: : = { slmLogs 3 } 

SlmValueChangeLogEntry OBJECT-TYPE 

SYNTAX SlmValueChangeLogEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"A single valuechange log. " 
INDEX {slmValueChangeLogTime} 
::= {slmValueChangeLogTable 1} 

SlmValueChangeLogEntry: := SEQUENCE { 

slmValueChangeLogName EntryName, 

SlmValueChangeLogTime TimeTicks, 

slmValueChangeLogText DisplayString, 

slmValueChangeLogChangedObjectld OBJECT IDENTIFIER 

} 

SlmValueChangeLogName OBJECT-TYPE 
SYNTAX EntryName 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The name of the logged event. " 
::= {SlmValueChangeLogEntry 1} 

SlmValueChangeLogTime OBJECT-TYPE 
SYNTAX TimeTicks 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The name of the logged event . " 
::= {SlmValueChangeLogEntry 2} 

SlmValueChangeLogText OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
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STATUS current 
DESCRIPTION 

"A description of the event's function and use. " 
DEFVAL { ' 'H} 
::= { slmValueChangeLogEntry 3} 

slmValueChangeLogChangedObjectld OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The object identifier of the MIB object that caused the event. " 
::= {SlmValueChangeLogEntry 4} 



Conformance Information 



slmCompliances OBJECT IDENTIFIER: : = { slmMIBConf ormance 1} 
slmGroups OBJECT IDENTIFIER: : = { slmMIBConf ormance 2} 

slmECMGCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent ECMGs . A hosting entity must also support either 
threshold, state change, or value change logs. " 
MODULE — this module 
GROUP slmThresholdLogControlGroup 
DESCRIPTION 

" This group is required if threshold logs are supported. " 
GROUP slmThresholdLogControlOpt Group 
DESCRIPTION 

" This group is optional if threshold logs are supported. " 
GROUP slmStateChangeLogControlGroup 
DESCRIPTION 

" This Group is required if stateChange logs are supported. " 
GROUP slmSt at eChangeLogControlOpt Group 
DESCRIPTION 

" This Group is optional if stateChange logs are supported. " 
GROUP slmValueChangeLogControlGroup 
DESCRIPTION 

" This Group is required valueChange logs are supported. " 
GROUP slmValueChangeLogControlOptGroup 
DESCRIPTION 

" This Group is optional valueChange logs are supported. " 
GROUP slmAlarmLogGroup 
DESCRIPTION 

" This group is required if alarm logs are supported. " 
GROUP slmAlarmLogOptGroup 
DESCRIPTION 

" This group is optional if alarm logs are supported. " 
GROUP slmStateChangeLogGroup 
DESCRIPTION 

" This Group is required if stateChange logs are supported. " 
GROUP slmValueChangeLogGroup 
DESCRIPTION 

" This Group is required valueChange logs are supported. " 
::= {slmCompliances 1} 

slmEmOrPdCompl lance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent EMMG/PDGs . A hosting entity must also support either 
threshold, state change, or value change logs. " 
MODULE — this module 
GROUP SlmThresholdLogControlGroup 
DESCRIPTION 

" This group is required if threshold logs are supported. " 
GROUP SlmThresholdLogControlOpt Group 
DESCRIPTION 

" This group is optional if threshold logs are supported. " 
GROUP SlmStateChangeLogControlGroup 
DESCRIPTION 

" This Group is required if stateChange logs are supported. " 
GROUP 3 ItnS tat eChangeLogControlOpt Group 
DESCRIPTION 

" This Group is optional if stateChange logs are supported. " 
GROUP SlmValueChangeLogControlGroup 
DESCRIPTION 
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" This Group is required valueChange logs are supported. " 
GROUP slmValueChangeLogControlOpt Group 
DESCRIPTION 

" This Group is optional valueChange logs are supported. " 
GROUP slmAlarmLogGroup 
DESCRIPTION 

" This group is required if alarm logs are supported. " 
GROUP slmAlarmLogOptGroup 
DESCRIPTION 

" This group is optional if alarm logs are supported. " 
GROUP slmStateChangeLogGroup 
DESCRIPTION 

" This Group is required if stateChange logs are supported. " 
GROUP slmValueChangeLogGroup 
DESCRIPTION 

" This Group is required valueChange logs are supported. " 
::= { slmCompliances 2} 

slmCpsigCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent CPSIGs. A hosting entity must also support either 
threshold, state change, or value change logs. " 
MODULE — this module 
GROUP slmThresholdLogControlGroup 
DESCRIPTION 

" This group is required if threshold logs are supported. " 
GROUP slmThresholdLogControlOpt Group 
DESCRIPTION 

" This group is optional if threshold logs are supported. " 
GROUP slmStateChangeLogControlGroup 
DESCRIPTION 

" This Group is required if stateChange logs are supported. " 
GROUP slmSt at eChangeLogControlOpt Group 
DESCRIPTION 

" This Group is optional if stateChange logs are supported. " 
GROUP slmValueChangeLogControlGroup 
DESCRIPTION 

" This Group is required valueChange logs are supported. " 
GROUP SlmValueChangeLogControlOpt Group 
DESCRIPTION 

" This Group is optional valueChange logs are supported. " 
GROUP SlmAlarmLogGroup 
DESCRIPTION 

" This group is required if alarm logs are supported. " 
GROUP SlmAlarmLogOptGroup 
DESCRIPTION 

" This group is optional if alarm logs are supported. " 
GROUP SlmStateChangeLogGroup 
DESCRIPTION 

" This Group is required if stateChange logs are supported. " 
GROUP SlmValueChangeLogGroup 
DESCRIPTION 

" This Group is required valueChange logs are supported. " 
::= {slmCompliances 3} 

slmCsigCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

" The compliance statement for SNMP Entities which host or 
represent CSIGs. A hosting entity must also support either 
threshold, state change, or value change logs. " 
MODULE — this module 
GROUP SlmThresholdLogControlGroup 
DESCRIPTION 

" This group is required if threshold logs are supported. " 
GROUP SlmThresholdLogControlOpt Group 
DESCRIPTION 

" This group is optional if threshold logs are supported. " 
GROUP SlmStateChangeLogControlGroup 
DESCRIPTION 

" This Group is required if stateChange logs are supported. " 
GROUP slmS tat eChangeLogControlOpt Group 
DESCRIPTION 

" This Group is optional if stateChange logs are supported. " 
GROUP SlmValueChangeLogControlGroup 
DESCRIPTION 

" This Group is required valueChange logs are supported. " 
GROUP SlmValueChangeLogControlOpt Group 
DESCRIPTION 

" This Group is optional valueChange logs are supported. " 
GROUP SlmAlarmLogGroup 
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DESCRIPTION 

" This group is required if alarm logs are supported. " 
GROUP slmAlarmLogOptGroup 
DESCRIPTION 

" This group is optional if alarm logs are supported. " 
GROUP slmStateChangeLogGroup 
DESCRIPTION 

" This Group is required if stateChange logs are supported. 
GROUP slmValueChangeLogGroup 
DESCRIPTION 

" This Group is required valueChange logs are supported. " 
::= { slmCompliances 4} 

slmAlarmLogGroup OBJECT-GROUP 
OBJECTS { 

slmAlarmLogName, 

slmAlarmLogTime, 

slmAlarmLogText, 

slmAlarmLogType, 

slmAlarmLogChangedOb jectid 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying alarm logs. " 
: := { slmGroups 1 } 

SlmAlarmLogOptGroup OBJECT-GROUP 
OBJECTS { 

slmAlarmLogCause, 

slmAlarmLogSeverity, 

slmAlarmLogTrendlndication, 

slmAlarmLogSpecif icProblems 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying alarm logs. " 
::= {slmGroups 2} 

SlmStateChangeLogGroup OBJECT-GROUP 
OBJECTS { 

slmStateChangeLogName, 

slmStateChangeLogTime, 

slmStateChangeLogText, 

s ImSt at eChangeLogChangedOb jectid, 

slmStateChangeLogToStateChange 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying state change logs. " 
::= {slmGroups 3} 

SlmValueChangeLogGroup OBJECT-GROUP 
OBJECTS { 

slmValueChangeLogName, 

slmValueChangeLogTime, 

slmValueChangeLogText , 

slmValueChangeLogChangedOb jectid 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying value change logs. " 
::= {slmGroups 4} 

slmThresholdLogControlGroup OBJECT-GROUP 
OBJECTS { 

slmLogControlName, 
slmLogControlTypes, 
slmLogControlCause , 
slmLogControlSeverity, 
slmLogControlTrendlndication , 
3 ImLogControlChangedOb jectid, 
slmLogControlStatus 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying threshold LOGCONTROLs. 
::= {slmGroups 5} 

slmThresholdLogControlOptGroup OBJECT-GROUP 
OBJECTS { 

slmLogControlStartTime, 

slmLogControlStopTime, 

slmLogControlDailyStartTime, 
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slmLogControlDailyStopTime, 

slmLogControlWeeklyMask, 

slmLogControlSpecif icProblems 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying threshold LOGCONTROLs. " 
::= {slmGroups 6} 

slmStateChangeLogControlGroup OBJECT-GROUP 
OBJECTS { 

slmLogControlName, 
slmLogControl Types, 
slmLogControlToStateChange, 
slmLogControlChangedObjectld, 
slmLogControlStatus 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying state change LOGCONTROLs. " 
: := { slmGroups 7 } 

slmStateChangeLogControlOptGroup OBJECT-GROUP 
OBJECTS { 

slmLogControlStartTime, 

slmLogControlStopTime, 

slmLogControlDailyStartTime, 

SlmLogControlDailyStopTime, 

SlmLogControlWeeklyMask, 

SlmLogControlSpecif icProblems 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying state change LOGCONTROLs. 
::= {slmGroups 8} 

slmValueChangeLogControlGroup OBJECT-GROUP 
OBJECTS { 

slmLogControlName, 
slmLogControlTypes, 
SlmLogControlChangedObjectld, 
SlmLogControlStatus 
} 

STATUS current 
DESCRIPTION 

" A collection of objects specifying value change LOGCONTROLs. " 
::= {slmGroups 9} 

slmValueChangeLogControlOptGroup OBJECT-GROUP 
OBJECTS { 

slmLogControlStartTime, 

slmLogControlStopTime, 

SlmLogControlDailyStartTime, 

SlmLogControlDailyStopTime, 

SlmLogControlWeeklyMask, 

SlmLogControlSpecif icProblems 
} 

STATUS current 
DESCRIPTION 

" A collection of optional objects specifying value change LOGCONTROLs. 
::= {slmGroups 10} 

END 
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